On Mon, 15 Jun 2015, Joseph Myers wrote: > > > 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.". > > See <http://grouper.ieee.org/groups/754/email/msg03893.html>: "The intent > is that NaNs which differ only in the sign bit are considered equivalent > for the purposes of 6.2.".
Fair enough, thanks for the pointer. This makes me wonder however what the point has been to specify a strict particular semantics for the copy, negate, abs, copySign operations with respect to the sign bit of qNaN data where any other operation can then change the bit in a random fashion. Do you happen to know what the rationale and any possible use cases considered have been? Furthermore these checks were deliberately introduced by Richard with his proposal here <http://gcc.gnu.org/ml/gcc-patches/2006-09/msg00682.html> and agreed upon in the discussion even before IEEE Std 754-2008 has been made. Are you suggesting that the arguments used there, that have led to the current arrangement, no longer stand and consequently the HONOR_NANS checks introduced are now best dropped? Maciej
