Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#1671 Exception thrown indirectly not caught when -O1 is specified

OTHER
open
nobody
Bug
none
Unknown
False
2013-02-11
2012-09-15
Edd
No

Windows XP Home + SP3

P:\guff>gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=m:/tools/mingw/4.7.0-1/bin/../libexec/gcc/mingw32/4.7.0/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.7.0/configure --enable-languages=c,c++,ada,fortran,objc,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared --enable-libgomp --disable-win32-registry --enable-libstdcxx-debug --disable-build-poststage1-with-cxx --enable-version-specific-runtime-libs --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.7.0 (GCC)

P:\guff>ld -v
GNU ld (GNU Binutils) 2.22

In particular, I have installed all the packages under "Runtime requirements:" in the readme file found here:
https://sourceforge.net/projects/mingw/files/MinGW/Base/gcc/Version4/gcc-4.7.0-1/

Discussion

  • Edd
    Edd
    2012-09-15

     
    Attachments
  • Edd
    Edd
    2012-09-15

    Sorry, I didn't realize "Add artifact" meant that the report would be submitted. I thought it was for finalizing attachments. So to finish the report...

    I'm building and running the attached C++ source file inside a regular Windows "command prompt" as follows:

    ----------
    P:\guff>g++.exe -O1 throw_copy.cpp -o throw_copy.exe

    P:\guff>throw_copy.exe
    terminate called after throwing an instance of 'derived_exception'
    what(): std::bad_alloc

    This application has requested the Runtime to terminate it in an unusual way.
    Please contact the application's support team for more information.
    P:\guff>
    ----------

    As you can see the process is terminate()d due to an uncaught exception, whereas I would expect the exception to be caught by the catch block in main().

    Some additional observations:

    - Works as I'd expect with gcc 4.6.2-1
    - Removing -O1 creates an executable that works as I'd expect. Any level of optimization seems to cause trouble.
    - The derived_exception class in the source multiply inherits from std::bad_alloc and base_exception. Removing bad_alloc from the base classes list allows the exception to be caught as I'd expect.
    - If ex.do_throw_copy() is called in main() instead of ex.throw_copy(), the exception is caught as I'd expect.

    I only have access to gcc 4.7 on Windows, so am unable to test for any platform-dependent behaviour.

     
  • Earnie Boyd
    Earnie Boyd
    2012-09-16

    The best place for your issue is the bugs list for GCC. We currently do not have anyone developing GCC with the mingw.org project.

     
  • Earnie Boyd
    Earnie Boyd
    2012-10-30

    Note, changing to this

    struct derived_exception : base_exception, std::bad_alloc
    {
    void do_throw_copy() const { throw derived_exception(*this); }
    };

    allows the program to function.

     
  • Earnie Boyd
    Earnie Boyd
    2012-10-30

    • status: open --> pending
     
  • Earnie Boyd
    Earnie Boyd
    2013-02-11

    • labels: gcc-4.7.0 --> gcc-4.7.0, gcc, g++
    • status: pending --> open
    • milestone: --> OTHER
    • type: --> Bug
    • resolution: --> none
    • category: --> Unknown
    • patch_attached: --> False