https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61441
--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Fri, 14 Aug 2015, ssaraswati at gmail dot com wrote: > --- 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. With -fno-signaling-nans, signaling NaN representations are trap representations - the compiler can assume that nothing ever manipulated as a floating-point value has such a representation. (It cannot assume anything about unions of floating-point and other types where the floating-point field is not accessed. But 58416 is a bug even in the absence of -fsignaling-nans.) > 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. In both these cases, we formally don't care about the result (but if folding, it still would seem odd to fold incorrectly, so may as well fold to a qNaN). > > 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? This point is nothing to do with -fsignaling-nans. It's a simple matter of C11 F.9.1 paragraph 3, "This specification does not require support for trap handlers that maintain information about the order or count of floating-point exceptions...." (which TS 18661-1:2014, adding support for signaling NaNs, doesn't change). But it's true that any references to a number of exceptions should make clear it's only referring to the distinction between zero and nonzero numbers. > 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? -ftrapping-math -frounding-math (but as I noted, -ftrapping-math doesn't really cover everything it should for that purpose, and something that did might not be suitable for enabling by default). > As for this issue, do you think modifying gcc to handle the default case would > be the right start? Local fixes for particular signaling NaNs issues seem reasonable (as in: if you fold an operation involving a signaling NaN, you may as well quiet it in the process, even though signaling NaNs aren't meant to occur in any mode where folding them is likely to be safe).
