MIN/MAX and trapping math and NANs

MIN/MAX and trapping math and NANs

[Andrew Pinski]

Hi,
  I noticed while working on phi-opt, that MIN/MAX EXPR (and the
corresponding RTL codes) both can return true for trapping even if
NANs are not honored (that is -ffinite-math-only). Is this true? I
would have assumed when -ffinite-math-only -fno-signed-zeros is used,
then MIN/MAX would be the same as a > b ? a : b which would not cause
a trap.

If we think they should not trap, then I will create a patch and test
it for GCC 14.

Thanks,
Andrew Pinski

Re: MIN/MAX and trapping math and NANs

[Richard Biener]

On Sat, 1 Apr 2023, Andrew Pinski wrote:

> Hi,
>   I noticed while working on phi-opt, that MIN/MAX EXPR (and the
> corresponding RTL codes) both can return true for trapping even if
> NANs are not honored (that is -ffinite-math-only). Is this true? I
> would have assumed when -ffinite-math-only -fno-signed-zeros is used,
> then MIN/MAX would be the same as a > b ? a : b which would not cause
> a trap.
> 
> If we think they should not trap, then I will create a patch and test
> it for GCC 14.

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 ...

I'm sure Joseph can clarify whether unconditionally returning
honor_snans (or false?) for MIN/MAX_EXPR from operation_could_trap_helper_p
would be correct.

Richard.

> Thanks,
> Andrew Pinski
> 

-- 
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

Re: MIN/MAX and trapping math and NANs

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 645 bytes --]

在 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)


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: MIN/MAX and trapping math and NANs

[LIU Hao]

[-- Attachment #1.1: Type: text/plain, Size: 395 bytes --]

在 2023/4/11 16:51, LIU Hao via Gcc 写道:
> 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)
> 

'the other is not' means the other operand is a QNaN; I'm not saying the other operand is not a NaN.


-- 
Best regards,
LIU Hao


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]

Re: MIN/MAX and trapping math and NANs

[Richard Biener]

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.

Re: MIN/MAX and trapping math and NANs

[Michael Matz]

Hello,

On Tue, 11 Apr 2023, Richard Biener via Gcc wrote:

> 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 IEEE 754-2008 predicate here is minNum/maxNum, and those are 
general-computational with floating point result.  That means any sNaN 
input raises-invalid (and delivers-qNaN if masked).  For qNaN input 
there's a special case: the result is the non-qNaN input (normal handling 
would usually require the qNaN to be returned).

Note that this makes minNum/maxNum (and friends) not associative.  Also, 
different languages and different hardware implement fmin/fmax different 
and sometimes in conflict with 754-2008 (e.g. on SSE2 maxsd isn't 
commutative but maxNum is!).  This can be considered a defect in 754-2008.  
As result these operations were demoted in 754-2019 and new functions 
minimumNumber (and friends) recommended (those propagate a qNaN).

Of course IEEE standards aren't publicly available and I don't have 
754-2019 (but -2008), so I can't be sure about the _exact_ wording 
regarding minimumNumber, but for background of the min/max woes: 

  https://754r.ucbtest.org/background/minNum_maxNum_Removal_Demotion_v3.pdf

In short: it's not so easy :-)  (it may not be advisable to slavishly 
follow 754-2008 for min/max)

> The NaN handling then possibly allows
> implementation with unordered compare + mask ops.


Ciao,
Michael.

Re: MIN/MAX and trapping math and NANs

[Joseph Myers]

On Tue, 11 Apr 2023, Michael Matz via Gcc wrote:

> Note that this makes minNum/maxNum (and friends) not associative.  Also, 
> different languages and different hardware implement fmin/fmax different 
> and sometimes in conflict with 754-2008 (e.g. on SSE2 maxsd isn't 
> commutative but maxNum is!).  This can be considered a defect in 754-2008.  
> As result these operations were demoted in 754-2019 and new functions 
> minimumNumber (and friends) recommended (those propagate a qNaN).

Yes.  fmax/fmin correspond to the IEEE 754-2008 operations.  C2x has new 
functions corresponding to the IEEE 754-2019 operations.

-- 
Joseph S. Myers
joseph@codesourcery.com