https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104356
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> --- Hmm, but doesn't ada enable -fdelete-dead-exceptions? That is, I'm not sure we make division by zero well-defined with -fnon-call-exceptions - the transform assumes the exception cannot happen (because undefinedness) and removes the exceptional path. So do we, with -fnon-call-exceptions, make division by zero throw an exception instead of invoking undefined behavior? (that is, on the non-exceptional path we can still assume the divisor is not zero after the division) Our docs say @item -fnon-call-exceptions @opindex fnon-call-exceptions Generate code that allows trapping instructions to throw exceptions. Note that this requires platform-specific runtime support that does not exist everywhere. Moreover, it only allows @emph{trapping} instructions to throw exceptions, i.e.@: memory references or floating-point instructions. It does not allow exceptions to be thrown from arbitrary signal handlers such as @code{SIGALRM}. This enables @option{-fexceptions}. which doesn't mention integer division by zero or arbitrary instructions of the ISA that may raise an exception under some circumstances (IIRC some x86 ones raise exceptions on overflow for example). Like the C standard would allow the CPU to raise an exception on out-of-bound shifts (since those invoke undefined behavior) - if the CPU would, would -fnon-call-exceptions imply it's now implementation defined (throw an exception?)? Of course integer division might be special enough to single out as IIRC all CPUs trap on that (I'm sure somebody knows one that does not...).