Re: [Mingw-users] GCC 4.3.0 20080502 (alpha) Released - Please help us test it!

[Charles Wilson <cwilso11@xxxxxxxxxxxxxxxxxxxxx>]

ATS wrote:
> So there seems to be a choice between:
> 
> 1 - DWARF - Fast but not robust with foreign frames. (any code generated
> by other compiler, in a plugin / DLL / static lib from 3rd party).
> 
> 2 - SJLJ - A bit slower but robust recovery in a mixed/plugin environment.

"A bit slower".  Try a whole hell of lot slower, as in: java is 
completely unusable in 4.3-sjlj.

> For me, the choice is 2 since I work with extensible apps. Since there 
> are so many compilers for Windows and run-time binary linking (plugin/
> COM) is common, it seems SJLJ is a better match. 

For those people who RIGHT THIS MINUTE must have 
exceptions-across-foriegn-frames working -- and are willing to stick 
with C/C++/Fortran (NOT java, and NOT Ada -- because the AdaCore stuff 
on which gcc's Ada relies now only supports DW2, AFAIK), then perhaps 
current 4.3.x-sjlj technology is a better choice.

For those who need foreign-frame support and are willing to continue to 
use 3.4.5 for another few months, while (1) the rest of us try to get 
DW2 stabilized for non-foreign-frame use, and (2) then start to solve 
the foreign-frame problem with DW2, I have a request of all the complainers:

Either get out of the way, and let those of us who don't need foreign 
frame support get on with (1) faster, so we can get to (2) sooner -- or 
start contributing code to gcc to fix (2) now. Bellyaching and harassing 
  Mr. LaFramboise is not helping ANYTHING.

It's amazing the number of folks coming out of the woodwork NOW to 
complain about the way Aaron is doing things -- where were YOU five 
months ago when Danny stepped down?  Or a year ago when he asked for 
help?  Thank [whatever you hold holy] for Aaron's efforts...

> If there is a try block inside a crucial tight inner loop, I'd just move 
> the try block out of there (I imagine one can shift the design slightly 
> in most cases).

It's not just "tight loops". And using STL at all, imposes a lot of 
try/catch inside the implementation. I don't want to "slightly" redesign 
the STL, nor eliminate its use, all so you can stick with old -- poorly 
supported by upstream gcc -- sjlj.

> If the choice is between:
> 
>  - Robust recovery in a mixed binary environment (with a cost for 
>    every 'try' block)
> 
>  - Very optimized performance in a controlled homogeneous environment
>    (limited, special circumstances, particularly on Windows)

All cygwin programs. Any computational program on windows. There's lots 
of stuff that is not GUI, and not networked. Or, perhaps IS 
gui/networked, but simply doesn't use the callback model.

> then that choice is easy enough for me.

And as upstream support for sjlj gets worse and worse, win32 becomes 
even more of a third-class citizen. Yippee.

How about we begin the switch to DW2, but maintain a separate 
C/C++/Fortran-only 4.3.x-sjlj UNTIL the foreign-frame problem with DW2 
is solved. then drop sjlj.

--
Chuck


-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
MinGW-users mailing list
MinGW-users@xxxxxxxxxxxxxxxxxxxxx

You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users