------- Comment #3 from kargl at gcc dot gnu dot org 2010-09-09 20:44 ------- (In reply to comment #2) > How do I open a glibc bug? > Although you say that the sign bit is set, thus you can have a negative NAN. > But it does not make much sense to allow this. A negative not-a-number is not > mathematically sensible. It wasn't the case in previous releases of the > library, so why did it just suddenly change? This change is causing some of > our > code to break, so we would like to investigate it more before we are able to > change code to accommodate new changes. >
I believe you may need to fix your code. The draft of the IEEE 754 standard (dated OCt 2006) I have states 8.2.1 NaN encodings in binary formats This clause further specifies the encodings of NaNs as bit strings when they are the results of operations. When encoded, all NaNs have a sign bit and a pattern of bits necessary to identify the encoding as a NaN and which determines its kind (sNaN vs. qNaN). The remaining bits, which are in the trailing field, encode the payload, which might be diagnostic information (see 8.2). 8.3 The sign bit When either an input or result is NaN, this standard does not interpret the sign of a NaN. Note however that operations on bitstrings copy, negate, abs, copySign specify the sign bit of a NaN result, sometimes based upon the sign bit of a NaN operand. The logical predicate totalOrder is also affected by the sign bit of a NaN operand. 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45620
