[llvm-dev] [cfe-dev] lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

[Gaetano Checinski via llvm-dev]

got a minimal example now:
    extern thread_local int tls;
    int main() {
        tls = 42;
        return 0;
    }

llvm-ir:
    ; ModuleID = 'main.cpp'
    target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
    target triple = "x86_64-pc-linux-gnu"

    @tls = thread_local global i32 0, align 4

    ; Function Attrs: norecurse uwtable
    define i32 @main() #0 {
      %1 = alloca i32, align 4
      store i32 0, i32* %1, align 4
      %2 = call i32* @_ZTW3tls()
      store i32 37, i32* %2, align 4
      ret i32 0
    }

    define weak_odr hidden i32* @_ZTW3tls() {
      ret i32* @tls
    }

    attributes #0 = { norecurse uwtable "disable-tail-calls"="false"
"less-precise-fpmad"="false" "no-frame-pointer-elim"="true"
"no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false"
"no-nans-fp-math"="false" "stack-protector-buffer-size"="8"
"target-cpu"="x86-64" "target-features"="+fxsr,+mmx,+sse,+sse2"
"unsafe-fp-math"="false" "use-soft-float"="false" }

    !llvm.ident = !{!0}

    !0 = !{!"clang version 3.8.1-12 (tags/RELEASE_381/final)"}


2017-02-07 16:19 GMT+00:00 Gaetano Checinski <gaetano.checinski at gmail.com>:

> > I’ve seen the same problem, but didn’t find solution back then.
> > I can give a hint that it is related to a thread local storage (notice
> TLS in the name).
> >
> > The same result can be reproduced by this simple program:
> >
> >    thread_local int x = 0;
> >    int main() {
> >      return 0;
> >    }
> >
> >When compiled into IR it produces similar error:
> >
> >LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP
> TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19]
> >  t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [TF=19]
> >In function: _ZTW1x
>
> interestingly this works on my machine.
>
> llvm-ir attached
>
>
>
> 2017-02-07 15:31 GMT+00:00 Alex Denisov <1101.debian at gmail.com>:
>
>> I’ve seen the same problem, but didn’t find solution back then.
>> I can give a hint that it is related to a thread local storage (notice
>> TLS in the name).
>>
>> The same result can be reproduced by this simple program:
>>
>>     thread_local int x = 0;
>>     int main() {
>>       return 0;
>>     }
>>
>> When compiled into IR it produces similar error:
>>
>> LLVM ERROR: Cannot select: t19: i64 = X86ISD::WrapperRIP
>> TargetGlobalTLSAddress:i64<i32* @x> 0 [TF=19]
>>   t18: i64 = TargetGlobalTLSAddress<i32* @x> 0 [TF=19]
>> In function: _ZTW1x
>>
>> > On 7 Feb 2017, at 16:13, Mehdi Amini via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>> >
>> > + LLVM-dev (clang is mostly about the frontend and this is a backend
>> failure), you may have more change to get an answer.
>> >
>> >> On Feb 6, 2017, at 5:49 AM, Gaetano Checinski via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>> >>
>> >> Running the following code with clang++ -S -emit-llvm main.cpp && lli
>> main.ll on Linux(Debian)
>> >>
>> >> #include <future>
>> >>
>> >>
>> >>
>> >> int main () {
>> >>
>> >>
>> >> return std::async([]{return 1;}).get();
>> >> }
>> >> fails to run on lli due to the following error:
>> >>
>> >> LLVM ERROR: Cannot select: 0xd012e0:
>> >>
>> >>      i64
>> >> = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8**
>> @_ZSt15__once_callable> 0 [TF=10]
>> >>
>> >>
>> >>
>> >> 0xd020c0: i64 = TargetGlobalTLSAddress<i8** @_ZSt15__once_callable> 0
>> [TF=10]
>> >> In function: _ZSt9call_onceIMNSt13__future_
>> base13_State_baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_
>> Result_baseENS4_8_DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
>> >> Questions:
>> >>
>> >> What does it mean?
>> >>
>> >> Are there any compiler-flags that fix this problem?
>> >>
>> >> what specific features is libstdc++ using that cause this issue ?
>> >>
>> >> How does my problem relate to Bug 21431 ?
>> >>
>> >> The motivation behind this questions is to understand the differences
>> between libc++ and libstdc++ that leads to this specific error message (on
>> Linux) in llvm's orcjit.
>> >>
>> >>
>> >>
>> >> ps.: i've also asked this question in stackoverflow
>> >>
>> >>
>> >>
>> >>
>> >>  Sent with Mailtrack
>> >>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170207/7031b421/attachment.html>