The following code asserts instead of completing normally. The constructor call to foo_base never happens, because of an exception during parameter set up. Unfortunately, the unwind code then calls the destructor on the never- constructed object. i686-pc-cygwin g++ 3.2 produces code that completes normally, i686-pc-mingw g++ 3.3.1 gets the assertion failure. #include <cassert> static unsigned int const kMagic = 0x0f00ba4e; struct foo_base { unsigned mConstructed; foo_base (void *) : mConstructed (kMagic) { } ~foo_base () { assert (mConstructed == kMagic); } }; void *check_ptr (void *ptr) { if (!ptr) throw ptr; return ptr; } int main (int argc, char *argv[]) { try { foo_base const &ref ((foo_base (check_ptr (0)))); } catch (void *) { } }
Created attachment 4771 [details] Assembly output from -save-temps Produced from the command f:/mingw/bin/g++ -o throw throw.cpp -save-temps
For me it's the other way round (on a linux box): with 3.2 I get the abort, with 3.3 and mainline the program terminates correctly. I guess this needs someone with a windows box to check. Giovanni? W.
Maybe this a generic sjlj exception handling problem? I'm not too clear on which compiler releases have used this mechanism, but the mingw compiler I have certainly does (note the --enable-sjlj-exceptions configure option below). Maybe the Linux versions mentioned by Wolfgang Bangerth used different EH mechanism between 3.2 and 3.3/mainline? $ f:/mingw/bin/gcc -v Reading specs from f:/mingw/bin/../lib/gcc-lib/mingw32/3.3.1/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as -- host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,objc,ada,java --disable-win32-registry --disable- shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x - -enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash- synchronization Thread model: win32 gcc version 3.3.1 (mingw special 20030804-1)
I can confirm this on the mainline (20030830) on i686-openbsd3.1 which uses sjlj exceptions but on the mainline (20030926) on i686-pc-linux-gnu (which uses dwarf exceptions) it is fine. Also on the mainline (20030925) on powerpc-apple-darwin (which also uses dwarf exceptions) the code does not produce an assert.
Seems to be fixed on mainline on mingw32 (using sjlj). Test case terminates normally. Reading specs from D:/MINGW/BIN/../lib/gcc/mingw32/3.4/specs Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as -- host=mingw32 --build=mingw32 --target=mingw32 --prefix=/mingw --enable-threads - -disable-nls --enable-languages=c,c++ --disable-win32-registry --disable- shared --enable-sjlj-exceptions --disable-libstdcxx-pch Thread model: win32 gcc version 3.4 20030928 (experimental)
The test case executes without assertion using Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as -- host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls -- enable-languages=c,c++,f77,objc,ada,java --disable-win32-registry --disable- shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x - -enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash- synchronization Thread model: win32 gcc version 3.3.2 20031007 (prerelease) Should this bug be marked as FIXED with target 3.3.2? Danny
Fixed two days after I tried this bug.