https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 21 Sep 2021, joseph at codesourcery dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54192 > > --- Comment #8 from joseph at codesourcery dot com <joseph at codesourcery > dot com> --- > On Tue, 21 Sep 2021, rguenther at suse dot de via Gcc-bugs wrote: > > > Yes, as said in other contexts GCC happily _removes_ traps if trapping > > is the only side-effect. _Unless_ you also have -fnon-call-exceptions > > enabled which is the only way to observe traps. So we consider > > a trap invoking undefined behavior unless you make them well-defined > > via -fnon-call-exceptions. > > That might be relevant to traps in the sense of changing control flow when > a floating-point exception is signaled. -fnon-call-exceptions doesn't > seem very relevant to the -ftrapping-math effects on transformations that > might affect the set of floating-point exception flags raised by some > code. As per my previous comment, -ftrapping-math currently affects (or > might affect if fully implemented) several different things: > > * Disallowing code transformations that cause some code to raise more > exception flags than it would have before. > > * Disallowing code transformations that cause some code to raise fewer > exception flags than it would have before. I might add that this particular point isn't followed thoroughly. > * Ensuring the code generated allows for possible non-local control flow > from exception traps raised by floating-point operations (this is the part > where -fnon-call-exceptions might be relevant). > > * Disallowing code transformations that might affect whether an exact > underflow exception occurs in some code (not observable through exception > flags, is observable through trap handlers). > > * Ensuring floating-point operations that might raise exception flags are > not removed, or moved past code (asms or function calls) that might read > or modify the exception flag state (not implemented, modulo Marc Glisse's > -ffenv-access patches from August 2020) And indeed while the above points are inter-mangled it might make sense to split -ftrapping-math into controls for the individual exception flag kinds (-ffinite-math-only overlaps here to some extent), or at least try to document the effects of the flags we have on the behavior of the exception state.
