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