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