This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/13668] New: thread local storage: static class member does not work
- From: "simon dot marshall at misys dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Jan 2004 14:51:52 -0000
- Subject: [Bug c++/13668] New: thread local storage: static class member does not work
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
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