https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38534
--- Comment #25 from Lukas Grätz <lukas.gra...@tu-darmstadt.de> ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to H.J. Lu from comment #18)
> > (In reply to Jakub Jelinek from comment #17)
> > > E.g. shouldn't it at least be disabled for -O0 and -Og and shouldn't we
> >
> > We can disable this for -O0 and -Og.
>
> I think we should go for that.
>
This is independent from debugging, but I thought the patch was only meant for
-O3. Have you thought about the following situation:
Compile with gcc -O1 (and --fno-exception is implicit):
---- library.c ----------------
void __attribute__((noreturn))
foo(void (*bar)(void)) {
...
bar();
while (1);
}
---------------------
Compile with g++ (and -fexception is implicit):
---- app.c++ ----------------
#include <iostream>
extern void foo(void (*bar)(void));
extern void bar_throws_exception(void) throw ();
int main() {
...
try
{
foo(bar_throws_exception);
}
catch (const std::exception& e)
{
...
}
}
----------------------
It is not hart to fill the ... to make it use some callee-saved registers (e.g.
with LOOP_BODY as in this issue report). And then the program would crash.
One might argue that either the library.c is to blame for the missing
-fexceptions? Or that the app.c++ is to blame because it should not call foo
with an argument function that might throw an exception? I am unsure if the C++
standard actually forbids calling C library functions with argument functions
that might throw an exception.
So I think it would be safer to restrict the patch to -O3. But I really don't
know much about this.
