Frank Heckenbach wrote:
Of course, for this also GPC should support thread local variables. ATM GPC does not support thread local variables, mainly because we want to have the same feature set with all backends and older backends (IIRC 3.2 and earlier) do not support them.
Same feature set where reasonably possible. As earlier GCC versions are already obsolescent (I don't want to drop them immediately, but is there any real need for versions before 3.4 anymore?), we should not waste any effort back-porting things. An error message when trying to use them with an earlier backend should be clear enough, so those who need threads will know they have to use 3.3 or newer.
BTW, how are they activated? As a special attribute or something like this? I.e., special handling in the frontend required only at declaration time, or also on usage?
See http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Thread-Local.html.
Thread-local storage (TLS) is a mechanism by which variables are allocated such that there is one instance of the variable per extant thread. The run-time model GCC uses to implement this originates in the IA-64 processor-specific ABI, but has since been migrated to other processors as well. It requires significant support from the linker (ld), dynamic linker (ld.so), and system libraries (libc.so and libpthread.so), so it is not available everywhere.
Not many targets support it (e.g. Darwin doesn't). So, I don't think we can use the feature (unfortunately).
At the user level, the extension is visible with a new storage class keyword: __thread. For example:
__thread int i; extern __thread struct state s; static __thread char *p;
Regards,
Adriaan van Os