This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/14563] octave built under Cygwin very slow


------- Additional Comments From paulthomas2 at wanadoo dot fr  2004-03-25 16:41 -------
Subject: Re:  octave built under Cygwin very slow

Hey come on!  For the "bug database dude" your grown-up talk is 
impressive enough to a toddler like me. Anyway,  I thank you for the 
explanation of setjmp/longjmp - it has been on my list of things to gen 
up on for a while.  It crosses my mind in discussing this that it is a 
bit aberrant to keep doing this within a loop of interpreted code, isn't it?

Anyhow, you will have seen Ben's message about trying a build with 
-fno-exceptions; as I suspected it did not get past quit.h.  I will put 
the question about the timing of the introduction of exceptions onto the 
list.  This perhaps will be the best route to settle the question as to 
whether or not sjlj is the root cause of the slow-down.

Thanks again

Paul Thomas

bangerth at dealii dot org wrote:

>------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]