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.
