<p dir="ltr"> > ldr r0, .LCPI0_0 (== pc-rel var)<br>
 >  add r0, pc</p>
<p dir="ltr"> > ldr r1, .LCPI0_1 (== pc-rel var)<br>
 > add r1, pc</p>
<p dir="ltr">Thank you for your technical support to resolve the bug of LLVM. I expect that the r268662 handles the situation of the referencing  different PC anchors  such as the above two LDRs with a dynamic TLS model (e.g., global-dynamic and local-dynamic)</p>
<p dir="ltr">ARMConstantPoolValue::hasSameValue(ARMConstantPoolValue *ACPV) {<br>
   if (ACPV->Kind == Kind &&<br>
       ACPV->PCAdjust == PCAdjust &&<br>
-      ACPV->Modifier == Modifier) {<br>
-    if (ACPV->LabelId == LabelId)<br>
-      return true;<br>
+      ACPV->Modifier == Modifier &&<br>
+      ACPV->LabelId == LabelId &&<br>
+      ACPV->AddCurrentAddress == AddCurrentAddress) {<br>
     // Two PC relative constpool entries containing the same GV address or<br>
     // external symbols. FIXME: What about blockaddress?<br>
     if (Kind == ARMCP::CPValue || Kind == ARMCP::CPExtSymbol)<br></p>
<p dir="ltr">BTW, the above "ACPV->AddCurrentAddress == AddCurrentAddress"  statement does also handle in case of other Oz/Os levels as well as O2/O3 optimization levels?</p>
<p dir="ltr">As I reported previously, we have not experienced a incorrect operation of __thread variable (via __tls_get_addr symbol) with O0/O1 flags. Maybe, does a key reason of this issue  is LLVM's inline transform pass (e.g., llvm-opt)?<br>
For example, <br>
O0 : noinline<br>
O1 : always-inline<br>
O2 : inline (always-inline)<br>
O3 : like O2<br>
Oz : ???<br>
Os : ??? <br><br></p>
<p dir="ltr">BRs,<br>
Geunsik Lim.<br>
</p>
<div class="gmail_quote">On May 6, 2016 3:44 AM, "Tim Northover" <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Geunsik,<br>
<br>
On 5 May 2016 at 02:42, Geunsik Lim <<a href="mailto:leemgs@gmail.com">leemgs@gmail.com</a>> wrote:<br>
> And, you can also download the assembly files (e.g. clsload.{ i | s | o })<br>
> that were generated by "-save-temps" flag.<br>
<br>
Thanks for making all these files for me. I think I've found the<br>
problem and it should be fixed in r268662. So now you get the fun of<br>
finding out just how dependent coreclr is on the precise llvm-3.5<br>
version they tell people to use!<br>
<br>
Cheers.<br>
<br>
Tim.<br>
</blockquote></div>