compilers that support thread-local storage?

[Michael Dickens]

OK wow that's quite the analysis! I'm going to go with just incorporating the c++11 1.1 PG ... it'll work for now, and once "we" get around to dealing with the changes to base from PR #88, it'll be a "universal" change to all Portfiles that use c++11 PGs ... so we'd be good to go! Thanks! - MLD

On Wed, Feb 13, 2019, at 1:23 PM, Ken Cunningham wrote:
> __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
>