https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112449
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to post+gcc from comment #10) > The standard says > > > This annex does not require the full support for signaling NaNs specified > > in IEC 60559. This > annex uses the term NaN, unless explicitly qualified, to denote quiet NaNs. > Where specification of > signaling NaNs is not provided, the behavior of signaling NaNs is > implementation-defined (either > treated as an IEC 60559 quiet NaN or treated as an IEC 60559 signaling NaN). I don't see implement-c.texi saying anything about this. Joseph, can you improve documentation here? > I have no idea how that allows a situation where the *output* of an > operation becomes signaling -- that can't usually happen no matter whether > the inputs are signaling or quiet. > > But that seems to be the common interpretation. > > Still, it seems important that `pow(1.0, 0.0/0.0)` returns `1.0` and not a > NaN. That's what the `pow` docs say. So for this there must be a guarantee > that `0.0/0.0` is a quiet NaN. GCC will not create an sNaN out of nowhere. But unless you enable -fsignaling-nans it is unspecified whether and when an sNaN will become a quiet NaN as GCC - as you observed - will happily elide x * 1.0 even when 'x' might be a sNaN (basically with -fno-signaling-nans GCC assumes that inputs are _never_ sNaN). The -fsignaling-nans might also need clarification to make it more obvious what omitting it means.
