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). -- Joseph S. Myers jos...@codesourcery.com
