mpfr 3.1.0 vs clang 3.0svn

Another data point on this problem. Using current llvm/dragonegg svn, I can compile libmpfr 3.1.0
using FSF gcc 4.6.2svn and the dragonegg plugin without any testsuite failures in libmpfr. Thus
it seems unlikely that the issue is in llvm but rather a problem introduced in clang itself.
       Jack
ps Interestingly, I can even compile libmpfr using llvm/dragonegg svn with the flags
-msse4 -fplugin-arg-dragonegg-enable-gcc-optzns to fully vectorize the code without
any failures in the libmpfr testsuite.

As we discussed it's likely a problem with TLS support in clang. I'm uncertain what the problem is, but I'll see if any of the TLS support tests I've got here have randomly started failing.

-eric

Eric,
   I doubt that would work as I can reproduce the problem with llvm.org's clang 2.9 release using Xcode 4.1.1's
cctools. I suspect we will shortly have a load of additional examples for you as fink 10.7 builds with the Xcode's
clang. Once Xcode 4.2 is released, every fink package which supports TLS will suddenly start to use it new builds.
                 Jack
ps Is there a clang flag to disable the TLS support (short of resorting to -mmacosx-version-min=10.6)?

Another data point on this problem. Using current llvm/dragonegg svn, I can compile libmpfr 3.1.0
using FSF gcc 4.6.2svn and the dragonegg plugin without any testsuite failures in libmpfr. Thus
it seems unlikely that the issue is in llvm but rather a problem introduced in clang itself.
     Jack
ps Interestingly, I can even compile libmpfr using llvm/dragonegg svn with the flags
-msse4 -fplugin-arg-dragonegg-enable-gcc-optzns to fully vectorize the code without
any failures in the libmpfr test suite.

As we discussed it's likely a problem with TLS support in clang. I'm uncertain what the problem is, but I'll see if any of the TLS support tests I've got here have randomly started failing.

-eric

Eric,
  I doubt that would work as I can reproduce the problem with llvm.org's clang 2.9 release using Xcode 4.1.1's
cctools.

I don't know what you mean here? That said, I'd need more information to try to debug anything.

I suspect we will shortly have a load of additional examples for you as fink 10.7 builds with the Xcode's
clang. Once Xcode 4.2 is released, every fink package which supports TLS will suddenly start to use it new builds.
                Jack
ps Is there a clang flag to disable the TLS support (short of resorting to -mmacosx-version-min=10.6)?

Nope, but it could be added.

-eric

>>
>>
>>> Another data point on this problem. Using current llvm/dragonegg svn, I can compile libmpfr 3.1.0
>>> using FSF gcc 4.6.2svn and the dragonegg plugin without any testsuite failures in libmpfr. Thus
>>> it seems unlikely that the issue is in llvm but rather a problem introduced in clang itself.
>>> Jack
>>> ps Interestingly, I can even compile libmpfr using llvm/dragonegg svn with the flags
>>> -msse4 -fplugin-arg-dragonegg-enable-gcc-optzns to fully vectorize the code without
>>> any failures in the libmpfr test suite.
>>
>> As we discussed it's likely a problem with TLS support in clang. I'm uncertain what the problem is, but I'll see if any of the TLS support tests I've got here have randomly started failing.
>>
>> -eric
>
> Eric,
> I doubt that would work as I can reproduce the problem with llvm.org's clang 2.9 release using Xcode 4.1.1's
> cctools.

I don't know what you mean here? That said, I'd need more information to try to debug anything.

Eric,
   From your comment above, "I'll see if any of the TLS support tests I've got here have randomly started failing.", I assumed
that you thought this was recent breakage in clang. My point was that I can reproduce this TLS breakage in MPFR 3.1.10 when
built with the fink llvm29 package (which is the llvm.org clang 2.9 release) under Xcode 4.1. This suggests that the problem
has existed as far back as clang 2.9 and is not recent breakage.
                  Jack

It's interesting. I'm not entirely sure what's going on, but my sniff of a couple of tests work, e.g.:

__thread int gTLSThreadID = 0;
int foobar() {
  return gTLSThreadID;
}
int main(void) {
  return foobar();
}

which generates the following code for foobar:

_foobar: ## @foobar
Ltmp2:
        .cfi_startproc
## BB#0: ## %entry
        pushq %rbp
Ltmp3:
        .cfi_def_cfa_offset 16
Ltmp4:
        .cfi_offset %rbp, -16
        movq %rsp, %rbp
Ltmp5:
        .cfi_def_cfa_register %rbp
        movq _gTLSThreadID@TLVP(%rip), %rdi
        callq *(%rdi)
        movl (%rax), %eax
        popq %rbp
        ret
Ltmp6:
        .cfi_endproc
Leh_func_end0:

and works just fine. I'd need more of a test case to see what's going wrong.

-eric

Eric,
   I'll see if I can get the mpfr developer to attempt to create a test case from his code.
So far, the only insight I have is that the issue is entirely suppressed if clang builds
mpfr 3.1.0 at -O0. This is required for both the libmpfr shared library build as well as
the test cases linked against it. Using -O1 triggers the testsuite failures. Interestingly
the exact test cases that fail and the way they crash seems to vary with the optimization
level (ie -O1 crashes the test cases differently than -O2). This does seem to suggest a
devtool bug. The mpfr author has seen a similar issues with other compilers...

http://www.loria.fr/~zimmerma/software/compilerbugs.html

                       Jack
ps As I mentioned before this problem doesn't exist with clang svn under x86_64 Fedora 15
so it appears to be entirely darwin11 specific.

  I'll see if I can get the mpfr developer to attempt to create a test case from his code.
So far, the only insight I have is that the issue is entirely suppressed if clang builds
mpfr 3.1.0 at -O0. This is required for both the libmpfr shared library build as well as
the test cases linked against it. Using -O1 triggers the testsuite failures. Interestingly
the exact test cases that fail and the way they crash seems to vary with the optimization
level (ie -O1 crashes the test cases differently than -O2). This does seem to suggest a
devtool bug. The mpfr author has seen a similar issues with other compilers...

http://www.loria.fr/~zimmerma/software/compilerbugs.html

                      Jack
ps As I mentioned before this problem doesn't exist with clang svn under x86_64 Fedora 15
so it appears to be entirely darwin11 specific.

That sounds totally reasonable. It could be a bug anywhere really :slight_smile:

Thanks!

-eric

Eric,
   I have opened radr://10291355, "Xcode 4.2 miscompiles tls support in MPFR 3.1.0", in radar.
The radar has an attached darwin11_clang_tls_bug.tar.bz2 test case which contains the libmpfr.4.dylib
and libfrtests.a libraries from MPFR built at -O0 as well as the preprocessed source for the
failing texceptions test case. The bad_build shell script demonstrates the miscompiled tls support
when texceptions.i is compiled by clang at -O2 and the good_build shell script demonstraties the
disappearance of the issue when texceptions.i is compiled by clang at -O0. This is as small a test
case that I can puzzle out.
   Hopefully the problem lies in clang and not the cctools from Xcode 4.2. If that is the case, I
can test any proposed fixes to clang svn (so that I can create additional test cases if tls-related
regressions in the MPFR testsuite remain).
             Jack

Eric,
    I uploaded darwin11_clang_tls_bug2.tar.bz2 to radar Problem ID: 10291355,"Xcode 4.2 miscompiles tls support in MPFR 3.1.0".
The new tarball provides an additional 11 testcases which fail when compiled at -O2 but not -O0 with clang's tls support.
Hopefully these will provide enough context to identify the origin of the problem and exhaustively test any fix.
         Jack