<div dir="ltr"><span class="gmail-mt-tool-email-notification-true"></span><span class="gmail-mt-tool-email-tracking-true"></span><span class="gmail-mt-tool-email-tracking-true"></span>Thanks for your quick answer.<div><br></div><div>> <span style="font-size:12.8px">It's a missing feature/bug in the x86 backend</span></div><div><span style="font-size:12.8px">did anyone try to implement an IR-transformer to emulate thread_local ?</span></div><div><br></div><div>> <span style="font-size:12.8px">JIT dynamic loader</span><span style="font-size:12.8px"> an't cope with the relocations that get generated.</span><br></div><div><span style="font-size:12.8px">how difficult would it be to fix this ?</span></div><div><br></div><img width="0" height="0" class="mailtrack-img" src="https://mailtrack.io/trace/mail/e9e6354b3f7890d9afb2c19023742da733de6dc1.png?u=931501"></div><div class="gmail_extra"><br><div class="gmail_quote">2017-02-07 15:35 GMT+00:00 Tim Northover <span dir="ltr"><<a href="mailto:t.p.northover@gmail.com" target="_blank">t.p.northover@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 6 February 2017 at 03:49, Gaetano Checinski via cfe-dev<br>
<span class=""><<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
> LLVM ERROR: Cannot select: 0xd012e0:<br>
>      i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8*<wbr>* @_ZSt15__once_callable> 0 [TF=10]<br>
><br>
>  0xd020c0: i64 = TargetGlobalTLSAddress<i8** @_ZSt15__once_callable> 0 [TF=10]<br>
> In function: _ZSt9call_onceIMNSt13__future_<wbr>base13_State_<wbr>baseV2EFvPSt8functionIFSt10uni<wbr>que_ptrINS0_12_Result_<wbr>baseENS4_8_<wbr>DeleterEEvEEPbEJPS1_S9_SA_<wbr>EEvRSt9once_flagOT_DpOT0_<br>
><br>
> Questions:<br>
><br>
> What does it mean?<br>
<br>
</span>It's a missing feature/bug in the x86 backend. The specific problem is<br>
that it seems we don't support thread-local variables with what Clang<br>
& GCC would call "-mcmodel=large".<br>
<br>
That's a compilation mode where the assembly is emitted that can run<br>
from anywhere in memory. During normal compilation "small" is used,<br>
the compiler assumes code will end up in the low 2GB of memory, and<br>
the linker makes sure this is true.<br>
<br>
Unfortunately when JITing, you can't usually guarantee that the OS<br>
will give you memory in the low 2GB so the default is "large", which<br>
is obviously less robust since it's less commonly used.<br>
<span class=""><br>
> Are there any compiler-flags that fix this problem?<br>
<br>
</span>Unfortunately it doesn't seem so. Using "lli -relocation-model=pic"<br>
gets around the immediate problem but then the JIT dynamic loader<br>
can't cope with the relocations that get generated.<br>
<span class="">> what specific features is libstdc++ using that cause this issue ?<br>
<br>
</span>Any thread-local storage would do it.<br>
<span class=""><br>
> How does my problem relate to Bug 21431?<br>
<br>
</span>Looks like exactly the same issue.<br>
<br>
Cheers.<br>
<span class="HOEnZb"><font color="#888888"><br>
Tim.<br>
</font></span></blockquote></div><br></div>