Make sure we will be able to use LLVM 3.4 on OS X

[dnadlinger]

We are not able to use LLVM 3.3 on OS X because it was released with a catastrophic regression regarding TLS: http://llvm.org/bugs/show_bug.cgi?id=15972. The bug was fixed in LLVM SVN r187913.

However, with current LLVM trunk the test suite does not pass on OS X either: Besides a strange crash in core.thread, there are notably some issues where the generated code crashes the system linker that comes with XCode 5 due to some issues with the TLV section.

We need to investigate this more closely and be sure to report the bugs to the upstream devs. Not being able to use 3.4 on OS X would be a disaster.

[redstar]

Just curious: is it the same failure as in issue #451? This seems to be a race condition in test "Multiple threads running shared fibers".

[dnadlinger]

Might be, didn't investigate it in detail yet.

[redstar]

@klickverbot Did you work on this issue? The release plan for LLVM 3.4 is now announced. (Branch on November 18th and release on December 23rd.)

[dnadlinger]

@redstar: A first bug report: http://llvm.org/bugs/show_bug.cgi?id=17964

There seems to be another issue w.r.t. exception handling, causing the std.file and std.parallelism test to crash in release mode. This vaguely reminds me of a similar issue in older LLVM versions.

[dnadlinger]

That old issue is #362, but the test case from there doesn't seem to trigger the issue anymore.

[dnadlinger]

@redstar: Did you get around to look into the floating point issue in std.math yet? If that's fixed, we shouldn't really be worse off with LLVM 3.4 than we were with 3.2 on OS X – the exception handling issue is present there as well, and that strange threading race condition occurs on other platforms as well.

[redstar]

I made no serious attempt to fix the std.math issue. I am still working on the 2.064 merge. (There is only slow progress but I am learning many things about LDC right now....)

[redstar]

I think I reduced the std.math problem. The following code

import core.stdc.stdio : printf;

enum real LOG2E =      0x1.71547652b82fe1777d0ffda0d23a8p+0L;

void print(real x)
{

    // real80
    ushort* pxe = cast(ushort *)&x;
    long*   pxs = cast(long *)&x;
    printf("%08x %08lx\n", cast(uint)(pxe[4]), pxs[0]);
}


void main()
{
    real x = -real.nan;
    print(x);
    x = LOG2E*x;
    print(x);
}

prints

0000ffff 00000000
0000ffff 00000000

when compiled with -O0 and

0000ffff 00000000
00007fff 00000000

when compiled with -O1/-O2/-O3. Somehow the sign bit is lost.

[redstar]

See http://llvm.org/bugs/show_bug.cgi?id=18048.

[dnadlinger]

Nice!

[redstar]

LLVM implements IEEE 754 floating point operations. One feature of the standard is that the sign bit of a NaN is not specified in general but only for a handful of operations.
LLVM was now changed to always generate a positive NaN. (If you can speak in terms of positive and negative if you don't have a number...). This conflicts with a unit test in std.math which assumed that the sign of a NaN is always preserved. I made a pull request to change this unit test. The error is now gone.

[redstar]

I am closing this issue as LLVM 3.4 is already released.