Re: MIN/MAX and trapping math and NANs
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 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
在 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 OpenPGP_signature Description: OpenPGP digital signature
Re: MIN/MAX and trapping math and NANs
在 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 OpenPGP_signature Description: OpenPGP digital signature
Re: MIN/MAX and trapping math and NANs
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
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
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 jos...@codesourcery.com
