www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - phobos unittests not passing with dmd built by clang

reply Trass3r <un known.com> writes:
I changed posix.mak as follows to compile with svn clang:

-HOST_CC=g++
+HOST_CC=clang++

-WARNINGS=-Wno-deprecated -Wstrict-aliasing
+WARNINGS=-Wno-deprecated -Wstrict-aliasing -Wno-logical-op-parentheses

-GFLAGS = $(WARNINGS) -D__near= -D__pascal= -fno-exceptions -O2
+GFLAGS = -x c++ $(WARNINGS) -D__near= -D__pascal= -fno-exceptions -O2


$ make MODEL=64 -f posix.mak -j2 unittest
Testing generated/linux/debug/64/unittest/std/format
several format tests disabled on x86_64 due to bug 5625
core.exception.AssertError std/format.d(2394): 1.67 -0X1.47AE147AE147BP+0  
-nan
----------------
generated/linux/debug/64/unittest/std/format(onUnittestErrorMsg+0x19)  
[0x4f5801]
generated/linux/debug/64/unittest/std/format(_d_unittest_msg+0x1f)  
[0x4ea1db]
generated/linux/debug/64/unittest/std/format(void  
std.format.__unittest46()+0x17b) [0x4948d3]
generated/linux/debug/64/unittest/std/format(void  
std.format.__modtest()+0x9f) [0x4e58bb]

Testing generated/linux/debug/64/unittest/std/math
core.exception.AssertError std.math(1891): unittest failure
----------------
generated/linux/debug/64/unittest/std/math(onUnittestErrorMsg+0x19)  
[0x464cf9]
generated/linux/debug/64/unittest/std/math(_d_unittestm+0x28) [0x460c1c]
generated/linux/debug/64/unittest/std/math(void  
std.math.__unittest_fail(int)+0x1d) [0x4601a5]
generated/linux/debug/64/unittest/std/math(void  
std.math.__unittest18()+0x15b) [0x45796f]
generated/linux/debug/64/unittest/std/math(void std.math.__modtest()+0x5e)  
[0x4600ce]



The autotester hasn't revealed this cause it still uses the old g++4.2 on  
OSX.
Apple switched to Clang just recently.

Can anyone confirm this?
If yes, bug in clang, dmd or phobos?
Jan 31 2012
next sibling parent reply Trass3r <un known.com> writes:
 Can anyone confirm this?
 If yes, bug in clang, dmd or phobos?

Note that the dmd testsuite passes for me.
Jan 31 2012
next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 31 Jan 2012 18:13:29 +0100, Trass3r <un known.com> 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.
Jan 31 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-01-31 19:56, Martin Nowak wrote:
 On Tue, 31 Jan 2012 18:13:29 +0100, Trass3r <un known.com> 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. -- /Jacob Carlborg
Jan 31 2012
parent reply Don Clugston <dac nospam.com> writes:
On 01/02/12 00:45, Martin Nowak wrote:
 On Tue, 31 Jan 2012 20:48:56 +0100, Jacob Carlborg <doob me.com> wrote:

 On 2012-01-31 19:56, Martin Nowak wrote:
 On Tue, 31 Jan 2012 18:13:29 +0100, Trass3r <un known.com> 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).
Feb 01 2012
parent reply dennis luehring <dl.soluz gmx.net> writes:
 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.

just a question: would it be a good idea to test this platform specific behavior in the phobos unit-tests? produce "an 80 bit load of a signalling NaN" check: intel: do not raise amd: do raise via: ... maybe only for showing that D is aware of this special cases?
Feb 01 2012
parent Don Clugston <dac nospam.com> writes:
On 01/02/12 09:44, dennis luehring wrote:
 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.

just a question: would it be a good idea to test this platform specific behavior in the phobos unit-tests? produce "an 80 bit load of a signalling NaN" check: intel: do not raise amd: do raise via: ... maybe only for showing that D is aware of this special cases?

It doesn't matter very much. If you load, and then do any operation (such as add) you'll get an exception. AMD will trigger one instruction earlier. Hardly anybody knows this -- I haven't found any references to it. It's in wikipedia, but the entry that mentions it was written by me! There is an underlying problem we have though. What _is_ T.init? If a variable of type T is default initialized as "this is uninitialized", what is T.init? In most cases, the compiler should give you a "variable XXX is used before set" error anyway.
Feb 01 2012
prev sibling next sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Tue, 31 Jan 2012 20:48:56 +0100, Jacob Carlborg <doob me.com> wrote:

 On 2012-01-31 19:56, Martin Nowak wrote:
 On Tue, 31 Jan 2012 18:13:29 +0100, Trass3r <un known.com> 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
Jan 31 2012
prev sibling parent "Martin Nowak" <dawg dawgfoto.de> writes:
On Wed, 01 Feb 2012 10:58:12 +0100, Don Clugston <dac nospam.com> wrote:

 On 01/02/12 09:44, dennis luehring wrote:
 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.

just a question: would it be a good idea to test this platform specific behavior in the phobos unit-tests? produce "an 80 bit load of a signalling NaN" check: intel: do not raise amd: do raise via: ... maybe only for showing that D is aware of this special cases?

It doesn't matter very much. If you load, and then do any operation (such as add) you'll get an exception. AMD will trigger one instruction earlier. Hardly anybody knows this -- I haven't found any references to it. It's in wikipedia, but the entry that mentions it was written by me! There is an underlying problem we have though. What _is_ T.init? If a variable of type T is default initialized as "this is uninitialized", what is T.init? In most cases, the compiler should give you a "variable XXX is used before set" error anyway.

"long double val = NAN;" This is sNaN for Clang and qNaN for GCC. -------------- At least on my Intel loading a sNaN and storing it in a double adds a sign. -------------- import std.stdio, std.math; void main() { ubyte[10] snan = [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0xFF, 0x7F]; ubyte[10] qnan = [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0xFF, 0x7F]; real srval = 0, qrval = 0; double sdval = 0, qdval = 0; asm { fld real ptr snan[RBP]; fst double ptr sdval[RBP]; fstp real ptr srval[RBP]; fld real ptr qnan[RBP]; fst double ptr qdval[RBP]; fstp real ptr qrval[RBP]; } writefln("%s %s %s %s", srval, signbit(srval), sdval, signbit(sdval)); writefln("%s %s %s %s", qrval, signbit(qrval), qdval, signbit(qdval)); } -------------- nan 0 nan 1 nan 0 nan 0
Feb 01 2012
prev sibling next sibling parent Iain Buclaw <ibuclaw ubuntu.com> writes:
On 31 January 2012 17:13, Trass3r <un known.com> wrote:
 Can anyone confirm this?
 If yes, bug in clang, dmd or phobos?

Note that the dmd testsuite passes for me.

As with a bug report. Get a reduced testcase. :) If I understand the error right, it asserts when trying to format a NaN? -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Jan 31 2012
prev sibling next sibling parent Trass3r <un known.com> writes:
Found out I forgot something in the makefile (such hardcoding really  
sucks!):

strtold.o: $C/strtold.c
-       gcc -m$(MODEL) -c $<
+       clang -m$(MODEL) -c $<

But it still fails.
Jan 31 2012
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/31/2012 9:03 AM, Trass3r wrote:
 The autotester hasn't revealed this cause it still uses the old g++4.2 on OSX.
 Apple switched to Clang just recently.

"gcc" on OS X 10.7, which I am using, defaults to using clang. So I am using clang on a regular basis, and have not seen issues.
Jan 31 2012
next sibling parent Trass3r <un known.com> writes:
 The autotester hasn't revealed this cause it still uses the old g++4.2  
 on OSX.
 Apple switched to Clang just recently.

"gcc" on OS X 10.7, which I am using, defaults to using clang. So I am using clang on a regular basis, and have not seen issues.

It's a really small corner case. Here's a fix: https://github.com/D-Programming-Language/dmd/pull/668
Jan 31 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-02-01 00:28, Walter Bright wrote:
 On 1/31/2012 9:03 AM, Trass3r wrote:
 The autotester hasn't revealed this cause it still uses the old g++4.2
 on OSX.
 Apple switched to Clang just recently.

"gcc" on OS X 10.7, which I am using, defaults to using clang. So I am using clang on a regular basis, and have not seen issues.

Really? I thought GCC perhaps used the LLVM backend on 10.7 but not the Clang frontend. LLVM != Clang. Seems scary that they just change what "gcc" invokes, specially on the command line. It's a totally different thing that they changed the default compiler in Xcode. -- /Jacob Carlborg
Jan 31 2012