https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114140
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to Xi Ruoyao from comment #16) > (In reply to Richard Biener from comment #15) > > It's the old argument on whether isnan(NaN) should return true or false with > > -ffinite-math-only. With what we currently do "constant folding" sNaN into > > NaN would be correct with -fno-signalling-nans, likewise constant folding > > Inf into 42.0 is "correct" for -ffinite-math-only. > > > > You are basically invoking undefined beavior when introducing sNaN into a > > program without using -fsignalling-nans. > > Then we should make it more clear in invoke.texi. Currently the doc is > implying the worst consequence using sNaN with -fno-signalling-nans is > "changing the number of raised exceptions." Yeah, the options that are not enabled by default (-fno-signalling-nans, -fno-trapping-math) could see improvement here. Usually -fno-X enables optimizations that would be invalid when X happens/is present. But that is nothing else than giving a free ticked to undefined behavior, maybe "constrained undefined behavior", but I'm not 100% sure we'd live up to that. Aka isnan (NaN) is optimized to false with -ffinite-math-only, something that's not valid when non-finite numbers are present. Whether doing so for literal NaN is "nice" remains questionable, but it's at least consistent with the behavior of x = NaN; isnan (x); So similarly -fno-signaling-nans enables optimizations that are not valid when sNaNs are present. Indeed "optimizations that may change the number of exceptions visible with signaling NaNs" is over-promising even if effectively this is all that happens.
