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