[cfe-dev] mpfr 3.1.0 vs clang 3.0svn

[Jack Howarth]

On Fri, Oct 14, 2011 at 02:50:32PM -0700, Eric Christopher wrote:
> 
> On Oct 11, 2011, at 5:26 PM, Jack Howarth wrote:
> 
> > On Tue, Oct 11, 2011 at 05:11:06PM -0700, Eric Christopher wrote:
> >> 
> >> On Oct 11, 2011, at 5:07 PM, Jack Howarth wrote:
> >> 
> >>> On Tue, Oct 11, 2011 at 04:52:37PM -0700, Eric Christopher wrote:
> >>>> 
> >>>> On Oct 11, 2011, at 7:48 AM, Jack Howarth wrote:
> >>>> 
> >>>>> 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.
> 
> 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 at 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.