On Mon, 15 Jun 2015, Joseph Myers wrote: > > operands negated. That negation, implemented with the IEEE Std 754-2008 > > `negate' operation that you referred to, by definition is required to > > operate on the sign of its operand in a specific way even if the operand > > is a qNaN. > > > > So for example `fmsM4', that is specified at the RTL level as (fma:M OP1 > > OP2 (neg:M OP3)) will not produce the correct result with the fused > > version of the MIPS MSUB.fmt instruction in the case where OP1 and OP2 are > > numeric data patterns and OP3 is a qNaN data pattern that has its sign bit > > clear. As specified by IEEE Std 754-2008 the (neg:M OP3) operation is > > required to invert the sign bit of the qNaN data pattern in calculating > > TMP3, and then the (fma:M OP1 OP2 TMP3) operation is required to pass the > > TMP3 qNaN data pattern unchanged in calculating the final result. > > It is only required (well, recommended) to pass the *payload*. The sign > bit is not part of the payload. "For all other operations, this standard > does not specify the sign bit of a NaN result, even when there is only one > input NaN, or when the NaN is produced from an invalid operation.".
However elsewhere: "For an operation with quiet NaN inputs, other than maximum and minimum operations, if a floating-point result is to be delivered the result shall be a quiet NaN which should be one of the input NaNs.". I think such a wording makes it clear that the input NaN bit pattern is propagated with no change whatsoever and I can't immediately infer if, for the purpose of standard interpretation, the clause you've quoted extends one that I have or whether one I've quoted narrows one that you have. Maybe this is a mistake/inconsistency in the standard. Of course you're right these are recommendations only ("should" vs "shall"), but I think we might want to have/keep a mode where IEEE Std 754 recommendations are strictly followed (where hardware permits). Maciej