18

After I declared a variable in this way:

   #include <thread>
   namespace thread_space
    {
    thread_local int s;
    } //etc.

i tried to compile my code using 'g++ -std=c++0x -pthread [sourcefile]'. I get the following error:

example.C:6:8: error: thread-local storage is unsupported for the current target
static thread_local int s;
       ^
1 error generated.

If i try to compile the same code on Linux with GCC 4.8.1 whit the same flags, i get a functioning executable file. I'm using clang-503.0.40 (the one which comes with Xcode 5.1.1) on a MacBook Pro running OSX 10.9.3. Can anybody explain me what i'm doing wrong? Thank you!!

pier94
  • 277
  • 1
  • 2
  • 8
  • If you ran the command `g++ -std=c++0x ...` then you are NOT using clang - you are using the extremely outdated version of GCC that ships with MacOS. Try `clang++ -std=c++11 ...` instead. – Casey May 21 '14 at 18:48
  • I've tried with the command that you suggested me, but the problem is the same: `Pier$ clang++ -std=c++11 -lpthread ./example.C ./example.C:6:1: error: thread-local storage is unsupported for the current target thread_local int s; ^ ` – pier94 May 21 '14 at 22:32
  • 4
    @Casey: `g++` is just a wrapper around `clang++` on OS X 10.9+. – Thomas May 25 '14 at 00:21
  • @Thomas They finally jettisoned their ancient GCC? Excellent. I obviously retract my comment. – Casey May 25 '14 at 01:14

4 Answers4

5

Try clang++ -stdlib=libc++ -std=c++11. OS X's outdated libstdc++ doesn't support TLS.

Edit

Ok, this works for the normal clang version but not for the Xcode one.

I did a diff against Apple's clang (503.0.38) and the normal released one and found the following difference:

        .Case("cxx_thread_local",
-                 LangOpts.CPlusPlus11 && PP.getTargetInfo().isTLSSupported() &&
-                 !PP.getTargetInfo().getTriple().isOSDarwin())
+                 LangOpts.CPlusPlus11 && PP.getTargetInfo().isTLSSupported())

So I think this is a bug in Apple's clang version (or they kept it in there on purpose - but still weird, because -v says based on 3.4).

Thomas
  • 3,074
  • 1
  • 25
  • 39
  • So do you think that is necessary to use an extern compiler and not Xcode's clang for using TLS or there might be a solution for fixing this bug? – pier94 May 25 '14 at 15:05
  • @pier94: The best would be to ask Apple why TLS is disabled in their Xcode version: https://bugreport.apple.com – Thomas May 25 '14 at 21:44
  • Ok, i've already sent an email to opensource@apple.com describing the situation and what turned out from the diff that you did. If within a week i don't get any answer I'll send an email to the address you've written. I'll let you know! – pier94 May 26 '14 at 08:58
  • @pier94: You won't get an answer there. You must open a bug report on http://bugreport.apple.com. – Thomas May 27 '14 at 08:10
  • At the moment i don't get any answer on [bugreport.apple.com](http://bugreport.apple.com/). When i'll receive any answer i'll let you know. – pier94 Jun 05 '14 at 19:44
  • It seems that i'm not the first one to have that problem. My report was closed because it seems to be a duplicate of another open issue. If you want to follow that report, its number is 9001553. – pier94 Jun 13 '14 at 21:37
  • It seems this issue is fixed and it works properly. (tested 26 Aug 2014) – Michel Aug 26 '14 at 01:31
  • @Michel: what version is that fixed in? Looks like there is still a problem in 3.5svn according to https://sft.its.cern.ch/jira/browse/ROOT-6524 . – dvj Sep 09 '14 at 21:05
  • I came across this and switched to gcc which compiles my code but the code faults when destructing the thread_local variable which leaves me wondering if the issue isn't somewhere in pthread (which std::thread() calls) or another library borking up the internals of the thread_local object I have (a vector>). v._M_impl._M_start gets set to NULL after function termination but before the thread returns. – Michael Conlen Apr 17 '15 at 14:55
  • This is ___not___ a bug. Apple has _consciously_ decided to remove the feature. See [here](http://clang.llvm.org/cxx_status.html): "thread_local support currently requires the C++ runtime library from g++-4.8 or later". – Emil Laine Jul 27 '15 at 16:47
  • @zenith: It *is* a bug in the clang darwin driver. `g++-4.8` has nothing to do with >= Mac OS X 10.7. – Thomas Jul 27 '15 at 17:18
  • @zenith: And FYI, this answer is about libc++ and not libstdc++, libc++ indeed supports thread_local. – Thomas Jul 27 '15 at 17:24
  • @Thomas Hmm, I get the error about unsupported `thread_local` with libc++, but not with libstdc++. – Emil Laine Jul 27 '15 at 17:32
  • @zenith: I do not get an error, neither with the vanilla clang nor with Apple's Xcode clang (clang-600.0.57). Note the comment: "It seems this issue is fixed and it works properly. (tested 26 Aug 2014)", maybe you are using an older version. – Thomas Jul 27 '15 at 17:44
  • @Thomas I'm using Xcode 7 beta on OS X 10.11 beta 2. Maybe this issue is coming back. – Emil Laine Jul 27 '15 at 17:45
  • @zenith: Ok, that's strange. What flags are you using and what's the output? – Thomas Jul 27 '15 at 17:46
  • 3
    @zenith: I just tried it with `Apple LLVM version 7.0.0 (clang-700.0.53)`, and indeed, `thread_local` doesn't work, not even with `libstdc++`. Consider filing a bug report. – Thomas Jul 27 '15 at 17:57
  • @Thomas `/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -x c++ -arch x86_64 -fmessage-length=0 -fdiagnostics-show-note-include-stack -fmacro-backtrace-limit=0 -stdlib=libc++ -fpascal-strings -O0 -DCMAKE_INTDIR=\"Debug\" -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk -fasm-blocks -fstrict-aliasing -mmacosx-version-min=10.11 -F/path/to/project/Debug -std=c++1y -pthread -fno-omit-frame-pointer -g3 -MMD -MT dependencies -MF /path/to/project/and/some/subdirs/main.d` [too long, continues…] – Emil Laine Jul 27 '15 at 17:59
  • `--serialize-diagnostics /path/to/project/and/some/subdirs/main.dia -c /path/to/main.cpp -o /path/to/main.o`. The output is `error: thread-local storage is not supported for the current target` on every line that has `thread_local`, nothing else. – Emil Laine Jul 27 '15 at 17:59
  • 1
    @zenith: You could have used pastebin :-). Anyway, see my previous comment, I think the bug(?) is back. – Thomas Jul 27 '15 at 18:07
  • @Thomas: Looks like this has finally been enabled in Xcode 8 Beta; see my new answer below. – rsfinn Jun 15 '16 at 19:02
3

Alternatively, you can use compiler extensions such as __thread (GCC/Clang) or __declspec(thread) (Visual Studio).

Wrap it in a macro and you can easily port your code across different compilers and language versions:

#if HAS_CXX11_THREAD_LOCAL
    #define ATTRIBUTE_TLS thread_local
#elif defined (__GNUC__)
    #define ATTRIBUTE_TLS __thread
#elif defined (_MSC_VER)
    #define ATTRIBUTE_TLS __declspec(thread)
#else // !C++11 && !__GNUC__ && !_MSC_VER
    #error "Define a thread local storage qualifier for your compiler/platform!"
#endif

...

ATTRIBUTE_TLS static unsigned int tls_int;
glampert
  • 4,371
  • 2
  • 23
  • 49
  • __thread also does not work on Mac OS X with clang giving this same problem while linking – Abhishek Jain Sep 21 '14 at 16:49
  • @AbhishekJain, that's mighty strange. I'm currently using it with Clang (v503.0.40) on Mac OS 10.9.5 (Mavericks). – glampert Sep 21 '14 at 20:39
  • Ah, of course, I'm using `clang++ -stdlib=libc++ -std=c++11`, so it must be it. – glampert Sep 21 '14 at 20:41
  • For me it is not working, neither thread_local nor __thread on Clang/XCode, Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.0.0 Thread model: posix. when i use __thread, then it gives linker error: ld: targeted OS version does not support use of thread local variables in __Z10TMM_Mallocm for inferred architecture x86_64. When i use thread_local, it gives compiler error: error: thread-local storage is unsupported for the current target. – Abhishek Jain Sep 22 '14 at 04:33
  • @AbhishekJain, this might be caused by some config setting of XCode. I compile directly via command line and it works. Try running a simple test directly on the terminal to see if it works, so you can narrow down your search. – glampert Sep 22 '14 at 13:51
  • -1, this doesn't do the exact same thing. __thread requires a trivial destructor for the type of the variable (i.e. you are limited to POD types). thread_local has no such restriction. – Tamás Szelei Mar 25 '16 at 10:57
  • @TamásSzelei, didn't know that. Removed that remark from the answer. However, depending on what the OP needed it for, it might not make a difference. – glampert Mar 25 '16 at 19:12
2

The clang compiler included in the Xcode 8 Beta and GM releases supports the C++11 thread_local keyword with both -std=c++11 and -std=c++14 (as well as the GCC variants).

Earlier versions of Xcode apparently supported C-style thread local storage using the keywords __thread or _Thread_local, according to the WWDC 2016 video "What's New in LLVM" (see the discussion beginning at 5:50).

rsfinn
  • 1,073
  • 14
  • 26
  • Leaving the Free/Net/OpenBSD guys as the last ones not supporting it. When everyone is providing a penalty free __thread local then maybe we will get a Python without a GIL someday. – Lothar Jun 21 '16 at 23:32
0

Seems like you might need to set the minimum OS X version you target to 10.7 or higher.

C. Scott Ananian
  • 1