__thread came first, then thread_local a bit later.
the difference is that thread_local allows more complicated initializers and
destructors ("non-trivial"). It is c++11, as you said.
quite old gcc versions support __thread I think the earliest one was gcc 4.1
<https://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Thread_002dLocal.html>
gcc 4.8+ supports thread_local
<https://www.gnu.org/software/gcc/gcc-4.8/changes.html>
For Open Source clang, we have this reference
<https://clang.llvm.org/cxx_status.html> that shows clang-3.3+ supported it
with a proper runtime. That runtime exists on 10.7+. As you know, I have
recently enabled "emulated thread_local" on clang-5.0+ (to match up with the
c++11 PG) for both stdlib=libc++ and stdlib=macports-libstdc++ (our c++11
runtimes). I wasn't planning on porting that back any further.
For Xcode clang, you already have that -- 900+. Apple introduced a
better-performance thread_local system that (as I understand it) involved
integration into dyld .
So gcc-4.8+ and clang-5.0+ is reliable on all systems using a c++11 runtime,
although there are some systems that can use thread_local with clang-3.4 to
clang-4.0 it appears (untested by me).
My idea was to make the cxx11 PG more or less == thread_local capability.
This has _all_ been changed in base recently by Marcus' base PR #88, so it's a
moving target.
Ken
