phobos unittests not passing with dmd built by clang

Don Clugston dac at
Wed Feb 1 00:32:42 PST 2012

On 01/02/12 00:45, Martin Nowak wrote:
> On Tue, 31 Jan 2012 20:48:56 +0100, Jacob Carlborg <doob at> wrote:
>> On 2012-01-31 19:56, Martin Nowak wrote:
>>> On Tue, 31 Jan 2012 18:13:29 +0100, Trass3r <un at> 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.

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

More information about the Digitalmars-d mailing list