c++ thread-local storage clang-503.0.40 (Mac OSX)

Asked 21/5, 2014 at 18:26 Answered 14/6, 2016 at 16:26

Solved xcode macos c++11 clang thread-local-storage

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!!

Flamethrower answered 21/5, 2014 at 18:26 Comment(4)

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. – Wife 21/5, 2014 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; ^

– Flamethrower 21/5, 2014 at 22:32

@Casey: g++ is just a wrapper around clang++ on OS X 10.9+. – Heriberto 25/5, 2014 at 0:21

@Heriberto They finally jettisoned their ancient GCC? Excellent. I obviously retract my comment. – Wife 25/5, 2014 at 1:14

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).

Heriberto answered 25/5, 2014 at 0:22 Comment(21)

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? – Flamethrower 25/5, 2014 at 15:5

@pier94: The best would be to ask Apple why TLS is disabled in their Xcode version: bugreport.apple.com – Heriberto 25/5, 2014 at 21:44

Ok, i've already sent an email to [email protected] 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! – Flamethrower 26/5, 2014 at 8:58

@pier94: You won't get an answer there. You must open a bug report on bugreport.apple.com. – Heriberto 27/5, 2014 at 8:10

At the moment i don't get any answer on bugreport.apple.com. When i'll receive any answer i'll let you know. – Flamethrower 5/6, 2014 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. – Flamethrower 13/6, 2014 at 21:37

It seems this issue is fixed and it works properly. (tested 26 Aug 2014) – Transmutation 26/8, 2014 at 1:31

@Michel: what version is that fixed in? Looks like there is still a problem in 3.5svn according to sft.its.cern.ch/jira/browse/ROOT-6524 . – Elery 9/9, 2014 at 21:5

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<vector<int>>). v._M_impl._M_start gets set to NULL after function termination but before the thread returns. – Present 17/4, 2015 at 14:55

This is not a bug. Apple has consciously decided to remove the feature. See here: "thread_local support currently requires the C++ runtime library from g++-4.8 or later". – Beaut 27/7, 2015 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. – Heriberto 27/7, 2015 at 17:18

@zenith: And FYI, this answer is about libc++ and not libstdc++, libc++ indeed supports thread_local. – Heriberto 27/7, 2015 at 17:24

@Heriberto Hmm, I get the error about unsupported thread_local with libc++, but not with libstdc++. – Beaut 27/7, 2015 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. – Heriberto 27/7, 2015 at 17:44

@Heriberto I'm using Xcode 7 beta on OS X 10.11 beta 2. Maybe this issue is coming back. – Beaut 27/7, 2015 at 17:45

@zenith: Ok, that's strange. What flags are you using and what's the output? – Heriberto 27/7, 2015 at 17:46

@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. – Heriberto 27/7, 2015 at 17:57

@Heriberto

/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…] – Beaut 27/7, 2015 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. – Beaut 27/7, 2015 at 17:59

@zenith: You could have used pastebin :-). Anyway, see my previous comment, I think the bug(?) is back. – Heriberto 27/7, 2015 at 18:7

@Thomas: Looks like this has finally been enabled in Xcode 8 Beta; see my new answer below. – Gratis 15/6, 2016 at 19:2

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;

Batory answered 19/8, 2014 at 22:9 Comment(7)

__thread also does not work on Mac OS X with clang giving this same problem while linking – Zavala 21/9, 2014 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). – Batory 21/9, 2014 at 20:39

Ah, of course, I'm using clang++ -stdlib=libc++ -std=c++11, so it must be it. – Batory 21/9, 2014 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. – Zavala 22/9, 2014 at 4: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. – Batory 22/9, 2014 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. – Persephone 25/3, 2016 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. – Batory 25/3, 2016 at 19:12

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).

Gratis answered 14/6, 2016 at 16:26 Comment(1)

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. – Dancette 21/6, 2016 at 23:32

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

Encephalomyelitis answered 9/10, 2015 at 22:44 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags