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...).
