Looking at the source code below, ompiling and linking without any extra options, one would expect the output of execution to be: c = nan And that is correct for GCC on RHEL5 and SLES10, with version 4.1.2. However, on RHEL6 and SLES11, starting with GCC version 4.3.4, the output is the following: c = -nan Which doesn't make much sense, since you can't really have a negative NAN. At the same time, when the code is compiled on RHEL5, and ran on RHEL6, the output still shows a negative NAN. It turns out that only compiling and linking statically (with -static) allows the results of RHEL5 to be achieved on RHEL6, and vice versa. This tells us that the libraries are responsible for this change. CODE: /* File name a.c */ int main() { double a = 0.0; double c = -(a/a); printf("c = %f\n", c); } COMPILE: gcc a.c RUN: ./a.out EXPECTED RESULTS: (identical to previous release of GCC) c = nan ACTUAL RESULTS: (starting with GCC 4.3.4) c = -nan
>negative NAN. Yes you can, the sign bit is set. But then again this is a glibc issue and not a GCC issue.
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.
(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.
The C99 standard says the sign should be printed even for NaN, see 7.19.6.1/8: ... "A double argument representing an infinity is converted in one of the styles [-]inf or [-]infinity — which style is implementation-defined. A double argument representing a NaN is converted in one of the styles [-]nan or [-]nan(n-char-sequence) — which style, and the meaning of any n-char-sequence, is implementation-defined. The F conversion specifier produces INF, INFINITY, or NAN instead of inf, infinity, or nan, respectively." ...