compilers that support thread-local storage?
michaelld at macports.org
Wed Feb 13 18:41:23 UTC 2019
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
> gcc 4.8+ supports thread_local
> 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
> 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.
More information about the macports-dev