[LLVMbugs] [Bug 19655] New: thread_local accessor function for 'primitive' variable in anonymous namespace has wrong linkage

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=19655

            Bug ID: 19655
           Summary: thread_local accessor function for 'primitive'
                    variable in anonymous namespace has wrong linkage
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
          Assignee: unassignedclangbugs at nondot.org
          Reporter: michael at ensslin.cc
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

For thread-local variables, clang++ auto-generates a wrapper that will
initialize the memory on first access. In contrast to g++, this also happens
for primitive types, e.g. ints or simple structs without constructors. For
those primitive types, the wrapper is globally linked in clang++, with
-std=c++11

Minimal example:

mic at mic-nb /tmp/repr4 $ cat a.cpp
namespace {

thread_local int i {1};

}

void f() {
    i = 2;
}
mic at mic-nb /tmp/repr4 $ cat b.cpp
namespace {

thread_local int i {0};

}

void f();

int main() {
    f();
    return i;
}
mic at mic-nb /tmp/repr4 $ g++ --version
g++ (GCC) 4.9.0
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

mic at mic-nb /tmp/repr4 $ clang++ --version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
mic at mic-nb /tmp/repr4 $ g++ -std=c++11 a.cpp b.cpp; ./a.out; echo $?
0
mic at mic-nb /tmp/repr4 $ clang++ -std=c++11 a.cpp b.cpp; ./a.out; echo $?
2

As you can see, f() in a.o influences the variable i from b.o.

mic at mic-nb /tmp/repr4 $ nm -C a.o
                 U _GLOBAL_OFFSET_TABLE_
0000000000000000 T f()
0000000000000000 d (anonymous namespace)::i
0000000000000000 W TLS wrapper function for (anonymous namespace)::i
mic at mic-nb /tmp/repr4 $ nm -C b.o
                 U _GLOBAL_OFFSET_TABLE_
0000000000000000 T main
                 U f()
0000000000000000 b (anonymous namespace)::i
0000000000000000 W TLS wrapper function for (anonymous namespace)::i
mic at mic-nb /tmp/repr4 $ nm -C a.out
(...)
00000000004005b0 T f()
0000000000000000 d (anonymous namespace)::i
0000000000000004 b (anonymous namespace)::i
00000000004005d0 t TLS wrapper function for (anonymous namespace)::i

As you can see, both variables are linked into the finaly binary, but one of
the TLS wrappers is scrapped.

If a more complex type is used instead of int, the error does not occur.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140505/4471ce4f/attachment.html>