Jump to page: 1 2
Thread overview
phobos unittests not passing with dmd built by clang
Jan 31, 2012
Trass3r
Jan 31, 2012
Trass3r
Jan 31, 2012
Iain Buclaw
Jan 31, 2012
Martin Nowak
Jan 31, 2012
Jacob Carlborg
Jan 31, 2012
Martin Nowak
Feb 01, 2012
Don Clugston
Feb 01, 2012
dennis luehring
Feb 01, 2012
Don Clugston
Feb 01, 2012
Martin Nowak
Jan 31, 2012
Trass3r
Jan 31, 2012
Walter Bright
Feb 01, 2012
Trass3r
Feb 01, 2012
Jacob Carlborg
January 31, 2012
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?
January 31, 2012
> Can anyone confirm this?
> If yes, bug in clang, dmd or phobos?

Note that the dmd testsuite passes for me.
January 31, 2012
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';
January 31, 2012
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.
January 31, 2012
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.
January 31, 2012
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
January 31, 2012
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.
January 31, 2012
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
February 01, 2012
>> 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
February 01, 2012
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
« First   ‹ Prev
1 2