RFR: 8230877: Rename THREAD_LOCAL_DECL to thread_local

[Kim Barrett]

> On Sep 11, 2019, at 6:58 PM, David Holmes <david.holmes at oracle.com> wrote:
> 
> Hi Per,
> 
> So if I read this right, the renaming will cause the C++11 thread_local to be used always on Windows (due to our use of VS 2017) but for Solaris Studio and gcc it will only be enabled if we explicitly ask for C++11 support - is that right?
> 
> I see Windows Visual Studio and Solaris Studio clearly state the equivalence of the two mechanisms. I'm expecting gcc is the same, but I don't see that clearly stated.

Well, bleh!  Thanks for making me look into that...

The release notes for gcc4.8 [1] (where thread_local support was added)
describes an important performance difference between thread_local and
__thread, and mentions a compiler option to remove that difference under
some circumstances.  It also suggests that because of this, one may want to
stick with __thread where it's still applicable.  (An initializer for a
__thread variable must be a constant expression. [3])

The gcc9.2 manual [2] (latest) describes the relevant option
(-fno-extern-tls-init). Maybe we can use that, but it puts some non-standard
(and well hidden) restrictions on our use of thread_local, which somewhat
defeats the point.

[1] https://gcc.gnu.org/gcc-4.8/changes.html 
[2] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/C_002b_002b-Dialect-Options.html#index-fextern-tls-init
[3] https://gcc.gnu.org/onlinedocs/gcc-9.2.0/gcc/Thread-Local.html#Thread-Local

Retracting my "Looks good”.  Fooey!