This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/13668] New: thread local storage: static class member does not work


A static class member should be able to be thread local:

class foo {
  static __thread int i;
};
__thread int foo::i = 0;
foo bar;

If bar.i is used in the same file as where bar is instantiated, then bar.i is 
indeed thread-local.  However, if bar.i is used in another file, then it is 
not.  This appears to be a bug.

Assuming I manage to attach the testcase to this report: The testcase contains 
3 source files: __thread.hpp, __thread.cpp defining foo(), __threadmain.cpp 
defining main().  Build a.out using the supplied Makefile.
__thread.hpp declares 2 classes, class Encap and template wrapper Templ.  Both 
contain static thread-local members.
__threadmain.cpp instantiates 3 objects: one a thread-local POD, one of Encap, 
one using Templ.  Its main() creates threads running function foo().
__thread.cpp foo() sets the POD and thread-local values of the Encap instance 
and Templ instance to the thread id.  It outputs the thread-local values and 
their addresses at the start of foo() and end of foo().

In the test case, only the POD appears to be thread-local.  The Encap instance 
and Templ instance are not.  The file a.1 shows that, as foo() exits in the 
different threads, the thread-local values are incorrect.  Not surprising, as 
the address of each of the thread-local members of Encap and Templ are the 
same.  This is a bug.

If the instantiations of Encap and Templ are moved from __threadmain.cpp to 
__thread.cpp (where foo() is defined and the instances are used), then all are 
thread-local.  The addresses of each of the thread-local members of Encap and 
Templ are different, as I would expect.  This is correct.

This is on rh9.
llama 200> gcc -v
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs
Configured with: ../configure --enable-shared --enable-threads=posix --with-
system-zlib --enable-__cxa_atexit
Thread model: posix
gcc version 3.3.2
llama 201> ld -v
GNU ld version 2.13.90.0.18 20030206
llama 202> as -v
GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version 
2.13.90.0.18 20030206
llama 203> uname -a
Linux llama 2.4.20-28.9smp #1 SMP Thu Dec 18 13:37:36 EST 2003 i686 i686 i386 
GNU/Linux

Note that the Solaris CC 5.5 compiler does the right thing.

-- 
           Summary: thread local storage: static class member does not work
           Product: gcc
           Version: 3.3.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: simon dot marshall at misys dot com
                CC: gcc-bugs at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13668


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]