From octave-maintainers-request at bevo dot che dot wisc dot edu Thu Mar 25 10:47:20 2004 Subject: [Fwd: [Bug c++/14563] octave built under Cygwin very slow] From: Paul Thomas To: octave-maintainers-list Date: Thu, 25 Mar 2004 17:47:21 +0100 This is a multi-part message in MIME format. --------------070705070702030501090901 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear All, You will see from the attached that the gcc maintainers propose two lines of attack: (i) To try to build octave with -fno-exceptions. Ben Diedrich tried this but the build did not get past quit.cc. (ii) To build and compare octave-before-exceptions with the two different gcc's. Does anybody know what version number we should be looking at? Paul T --------------070705070702030501090901 Content-Type: message/rfc822; name="[Bug c++/14563] octave built under Cygwin very slow" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="[Bug c++/14563] octave built under Cygwin very slow" Return-Path: Received: from mwinf0503.wanadoo.fr (mwinf0503.wanadoo.fr) by mwinb0606 (SMTP Server) with LMTP; Thu, 25 Mar 2004 15:37:05 +0100 X-Sieve: Server Sieve 2.2 Received: from sources.redhat.com (sources.redhat.com [67.72.78.213]) by mwinf0503.wanadoo.fr (SMTP Server) with SMTP id 6005A18000C9 for ; Thu, 25 Mar 2004 15:37:05 +0100 (CET) Received: (qmail 5215 invoked by uid 48); 25 Mar 2004 14:37:03 -0000 Date: 25 Mar 2004 14:37:03 -0000 Message-ID: <20040325143703 dot 5214 dot qmail at sources dot redhat dot com> From: "bangerth at dealii dot org" To: paulthomas2 at wanadoo dot fr In-Reply-To: <20040312233606 dot 14563 dot paulthomas2 at wanadoo dot fr> References: <20040312233606 dot 14563 dot paulthomas2 at wanadoo dot fr> Reply-To: gcc-bugzilla at gcc dot gnu dot org Subject: [Bug c++/14563] octave built under Cygwin very slow X-Bugzilla-Reason: Reporter ------- Additional Comments From bangerth at dealii dot org 2004-03-25 14:36 ------- SJLJ stands for "setjmp/longjmp". I'm not an expert in this field (as I know virtually nothing about the gcc interiors anyway, I'm just the bug database dude), but here's the idea: when you call a function that may or may not throw an exception, and the calling function needs to run destructors of local objects in case an exception is thrown, you need to put down the address of the cleanup code somewhere. One way to do this is to set this address via setjmp, and throwing an exception then transfers control to this place via longjmp. This is expensive since you have to call setjmp every time a cleanup is necessary. The other possibility is to use lookup tables that the compiler generates statically, so this is cheap at run-time, but incurs some code overhead. If you generate an exception, you have to somehow look up where to transfer execution. Don't ask me how exactly this works, but it is to my best knowledge how dwarf2 exception unwinding works. Corrections on this topic my more knowledgable people are certainly welcome. Now back to the question how we can figure out what the problem is: if using -fno-exceptions doesn't work, is there a possibility you repeat your experiments with an octave version prior to the introduction of exceptions? W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563 ------- You are receiving this mail because: ------- You reported the bug, or are watching the reporter. --------------070705070702030501090901--