https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #6 from Sujoy <ssaraswati at gmail dot com> --- (In reply to jos...@codesourcery.com from comment #5) > With -fno-signaling-nans we don't really care about the result value. I am not sure about this. -fno-signaling-nans is default and the original issue mentions that "under default exception handling, any operation signaling an invalid operation exception and for which a floating-point result is to be delivered shall deliver a quiet NaN". If we have to honor the default exception handling case, we need to convert the sNaN to qNaN here. Let me know if I missed something. > More precisely, exceptions are relevant with -fsignaling-nans > -ftrapping-math but even with -fno-trapping-math it's still visible if the > result is wrongly a sNaN instead of a qNaN. (-ftrapping-math is the > default. It's not clear there's any use for -fsignaling-nans > -fno-trapping-math. But -fsignaling-nans is the option that says there > may be signaling NaN arguments, and -ftrapping-math is the option that > says we care about exceptions.) The man page entry for -fno-trapping-math says "This option requires that -fno-signaling-nans be in effect." The description for -fsignaling-nans says "This option implies -ftrapping-math." Hence, only the following combinations should be valid - 1) -fno-trapping-math and -fno-signaling-nans 2) -ftrapping-math and -fno-signaling-nans (default) 3) -ftrapping-math and -fsignaling-nans Here is my understanding - For case 1, we can go ahead with optimizations that may remove operations that may lead to exceptions, as we don't care about them. Also, we convert sNaN to qNaN since -fno-signaling-nans is on. For case 2, we can do the transformation like folding and they should convert sNaN to qNaN since -fno-signaling-nans is on. For case 3, we have to disallow certain transformation so that any operation leading to exception due to sNaN is not optimized away. > The *number* of exceptions isn't relevant, only the set raised at any > point (e.g. function call) where the raised exceptions may be tested or > modified; it's valid to change one nonzero number of times raising a given > exception between two such points to a different nonzero number of times > raising that exception. Thanks for this information. Does this mean that the man page description of -fsignaling-nans is too restrictive? > I'm sure there are lots of optimizations that wrongly discard exceptions, > whether for signaling NaNs or other operands. > > Roughly, the present -ftrapping-math seems to be implemented as meaning > that an expression shouldn't be transformed to change the exceptions > raised, but exceptions aren't treated as side effects so it can still be > discarded if apparently unused, or moved past code that might test or > modify exceptions. Something stricter that actually follows Annex F would > treat exceptions more like side effects and eliminate a lot of code > movement / dead code removal. It might be less suitable for the default > compilation mode, however. > > I expect there are plenty of bugs even with that more limited description > of what -ftrapping-math tries to do. I was referring to the Annex F of C99 ISO IEC 9899 1999, it says - "An operation on constants that raises no floating-point exception can be folded during translation, except, if the state of the FENV_ACCESS pragma is ββonβ..." What is the equivalent of checking FENV_ACCESS on within gcc? As for this issue, do you think modifying gcc to handle the default case would be the right start? Regards, Sujoy
