[Bug libquadmath/114140] different results for std::fmin/std::fmax and quadmath fminq/fmaxq if one argument=signaling_NaN

[rguenth at gcc dot gnu.org]

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.