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!
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 ac
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
在 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 QN
在 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/fmi
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 -
