On 01/02/12 00:45, Martin Nowak wrote:
On Tue, 31 Jan 2012 20:48:56 +0100, Jacob Carlborg <[email protected]> wrote:
On 2012-01-31 19:56, Martin Nowak wrote:
On Tue, 31 Jan 2012 18:13:29 +0100, Trass3r <[email protected]> wrote:
Can anyone confirm this?
If yes, bug in clang, dmd or phobos?
Note that the dmd testsuite passes for me.
Clang behaves differently, but it's probably not a bug.
----
#include <stdio.h>
#include <math.h>
int main()
{
long double foo = NAN;
double a = foo;
double b = NAN;
double c = fabs(NAN);
printf("%Lf %d\n", foo, (int)signbit(foo));
printf("%f %d\n", a, (int)signbit(a));
printf("%f %d\n", b, (int)signbit(b));
printf("%f %d\n", c, (int)signbit(c));
}
----
double a = foo; // seems like "FSTP m64fp" doesn't preserve the sign bit
We need to fix the code in PortInitializer::PortInitializer() which
relies on
sign preserving of NaN size conversions.
I thought Clang would be compatible with GCC.
I think it's undefined behavior to rely on the exact representation of NaN.
From what I've seen whether "a" ends up with a sign or not depends on
processor
internal state and is not specified by Intel, clang emits different code
thus the difference.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1486.htm
The behaviour of the sign bit is completely specified in the x86
manuals. As that link says, the C standard got it wrong in a couple of
places.
The one thing which is implementation specific is that on Intel, an 80
bit load of a signalling NaN doesn't raise an exception, whereas it does
on AMD. I don't know what Via does.
Also, when an invalid operation occurs, the exact bit pattern you get is
implementation specific. For example on PowerPC you get a different bit
pattern for 0/0 compared to sqrt(-1), while on x86 you get the same bit
pattern for all of them. But, it is mandatory that NaN payloads be
preserved. (Except for casts from double <-> float, that must obviously
destroy the payload, probably in an implementation-specific way).
