On Thu, May 5, 2022 at 7:11 PM Joseph Myers <[email protected]> wrote: > > On Thu, 5 May 2022, Richard Biener via Gcc-patches wrote: > > > MIN/MAX_EXPR shouldn't even appear with -fsignalling-nans for this > > reason, at least that's what I thought. But yes, you might have a point > > here (but maybe it's also not strictly enough specified). One option would > > be to do (minmax == MAX_EXPR || minmax == MIN_EXPR || !tree_expr ...) > > > > Joseph - are MIN_EXPR and MAX_EXPR supposed to turn sNaN into qNaN > > and the 'undefinedness' is merely as to which operand is chosen? > > I don't know what MIN_EXPR and MAX_EXPR are supposed to do with sNaN > arguments. As noted, the fmax and fmin functions should produce a qNaN > result with the "invalid" exception raised (so with an sNaN argument, it's > definitely not valid to fold them in the absence of -fno-trapping-math; > with -fsignaling-nans -fno-trapping-math, if an argument is known to be > sNaN it would be valid to fold to qNaN, but I doubt there's much use of > that option combination). > > C never attempts to define which qNaN result (choice of payload or sign > bit) is produced by an operation and I don't think our optimizations > should be trying to define that (with any command-line options currently > supported) either (other than for non-computational operations such as > fabs and copysign, but even there there is scope for > implementation-defined handling of assignment as a convertFormat operation > rather than a copy operation). Note that while some architectures > propagate NaN payloads from a NaN operand to an instruction, others (e.g. > RISC-V) do not, and when payloads are propagated there would still be the > matter of which payload is chosen when there is more than one NaN operand > (on x86, that is handled differently for SSE and x87 instructions).
Thanks. So I think the patch as posted is correct on the safe side in letting the CPU to decide what happens with sNaNs. As said, the chance seeing an sNaN and MAX/MIN_EXPR is low. So I'm defering to the poster if he wants to re-post with treating MIN/MAX_EXPR special in the optimistic sense. Richard. > -- > Joseph S. Myers > [email protected]
