[cfe-dev] mpfr 3.1.0 vs clang 3.0svn

[Eric Christopher]

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