[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag

[Geunsik Lim via llvm-commits]

> ldr r0, .LCPI0_0 (== pc-rel var)
>  add r0, pc

> ldr r1, .LCPI0_1 (== pc-rel var)
> add r1, pc

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)

ARMConstantPoolValue::hasSameValue(ARMConstantPoolValue *ACPV) {
   if (ACPV->Kind == Kind &&
       ACPV->PCAdjust == PCAdjust &&
-      ACPV->Modifier == Modifier) {
-    if (ACPV->LabelId == LabelId)
-      return true;
+      ACPV->Modifier == Modifier &&
+      ACPV->LabelId == LabelId &&
+      ACPV->AddCurrentAddress == AddCurrentAddress) {
     // Two PC relative constpool entries containing the same GV address or
     // external symbols. FIXME: What about blockaddress?
     if (Kind == ARMCP::CPValue || Kind == ARMCP::CPExtSymbol)

BTW, the above "ACPV->AddCurrentAddress == AddCurrentAddress"  statement
does also handle in case of other Oz/Os levels as well as O2/O3
optimization levels?

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)?
For example,
O0 : noinline
O1 : always-inline
O2 : inline (always-inline)
O3 : like O2
Oz : ???
Os : ???

BRs,
Geunsik Lim.
On May 6, 2016 3:44 AM, "Tim Northover" <t.p.northover at gmail.com> wrote:

> Hi Geunsik,
>
> On 5 May 2016 at 02:42, Geunsik Lim <leemgs at gmail.com> wrote:
> > And, you can also download the assembly files (e.g. clsload.{ i | s | o
> })
> > that were generated by "-save-temps" flag.
>
> Thanks for making all these files for me. I think I've found the
> problem and it should be fixed in r268662. So now you get the fun of
> finding out just how dependent coreclr is on the precise llvm-3.5
> version they tell people to use!
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160506/56043d45/attachment-0001.html>