Re: MIN/MAX and trapping math and NANs

[Richard Biener <rguenther@suse.de>]

On Tue, 11 Apr 2023, LIU Hao wrote:

> ? 2023/4/11 16:00, Richard Biener via Gcc ??:
> > I think without NaNs MIN/MAX cannot raise any exceptions (I'm not
> > even sure whether MIN/MAX involving NaN will set invalid, but
> > most certainly with sNaN it will trap and return a quiet NaN?).
> > The C standard doesn't
> > document any exceptions for fmax/fmin (even with NaN), but
> > meanwhile there's a plethora of min/max function variants ...
> 
> My interpretation is that if one argument is a SNaN and the other is not,
> `fmax()` shall return the SNaN unchanged, without converting it to a QNaN.
> (F.10.9.2 The fmax functions, ISO/IEC 9899:2017)

I see.  I'll note that the x86 maxpd instruction (which doesn't
conform to IEEE with its handling of NaN) raises INVALID on sNaN
and qNaN operands and apperantly also DENORMAL.

In the case we ever implement conforming FP exception support
either targets would need to be fixed to mask unexpected exceptions
or we have to refrain from moving instructions where the target
implementation may rise exceptions across operations that might
raise exceptions as originally written in source (and across
points of FP exception state inspection).

That said, the effect to the FP exception state according to IEEE
is still unanswered.  The NaN handling then possibly allows
implementation with unordered compare + mask ops.

Richard.