------- 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.



Reply via email to