Non-call-exceptions, unwinding and g++ optimization levels
Jorge Bellón Castro
jbelloncastro@gmail.com
Wed Jan 21 11:13:00 GMT 2015
Good day,
I'm working with exceptions thrown by a signal handler using
-fnon-call-exceptions flag with g++ for x86_64.
The problem I am facing is that the behavior of this mechanism is not
consistent if we change some optimization options, that is, the result
of a given program can be different. In order to make a comparison, I
ran this test several times, each with different optimizations
enabled.
Compilation either with -O0 or without any flags (just -fnon-call-exceptions):
Exception is caught at the "copy" function (the one which calls
std::copy). This is the expected behavior.
Compilation using -O1 -O2 or -O3 flag directly:
Exception is not being caught.
If both -fno-inline and -fno-ipa-pure-const are used, then the program
behaves as if -O0 is used. Thus, I tried to add
__attribute__((noinline)) to both "foo" and "copy" functions. It seems
that they were ignored because the problem doesn't dissapear when
-fno-inline is not used.
In my opinion, it seems that catch blocks are being optimized out or
that, because of the inlining, the generated code is not able to find
any catch blocks inside its scope.
I could reproduce this with g++ versions 4.7.3, 4.8.1 and the latest
in the public, read-only, git. The file used to test this is attached
to the message. Compile command used is:
g++ -fnon-call-exceptions [-fno-inline -fno-ipa-pure-const] -O{0,1,2,3}
Regards,
Jorge
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ncetest.cpp
Type: text/x-c++src
Size: 1702 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20150121/b1480c22/attachment.bin>
More information about the Gcc
mailing list