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.
