https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26461
--- Comment #15 from torvald at gcc dot gnu.org --- From a ISO C/C++ conformance perspective, this is not a bug: * Pre-C11/C++11, threading was basically undefined. * Starting with C11 and C++11, "threads of execution" (as they're called in C++11 and more recent, often abbreviated in the standard as "threads") are the lowest level of how execution is modelled. They are defined as single flows of control. Nothing is promised about any resources that may be used to implement threads of execution (e.g., similar to the "execution context" notion mentioned in comment #10). * Thread-specific state is bound to a particular thread of execution (e.g., regarding lifetime). A thread of execution accessing a __thread variable accesses the thread-specific state of this thread of execution in the abstract machine. (Of course, one can still access other threads's thread-specific state through pointers initially provided by those threads.) * Only the standards' mechanisms can create threads of execution. There is nothing in these standards that would break up the concept of a single flow of control (ie, that what "looks" like a single flow of control in a program is actually not always the same thread of execution when executed). (Also note that fork/join parallelism is not a counter-example to this.) That said, I can see that this doesn't match nicely with the fact that we have things like swapcontext elsewhere. Do we have any data on what the performance impact where if the compiler would assume that function calls to functions it cannot analyze could switch the thread of execution. Data for several architectures and different TLS models would be helpful. Coming back to C++, currently I think there is only one Technical Specification (TS) that allows breaking up a single flow of control: .then() in the Concurrency TS (whose specification is certainly not ready for the standard). Maybe the Networking TS has something similar, but I can't remember right now. There are a few proposals that either allow it (Task Blocks, targeting Parallelism TS version 2) or require it for good performance ("stackful" coroutines). The "stackless" coroutines in the upcoming Coroutines TS are not really affected by thread-specific state; it's not the coroutines code that would potentially switch threads, but any runtime that would supply a particular Awaitable implementation that then may switch threads (e.g., if using .then()). The Coroutines does not specify any actual runtime. However, I don't think the existence of some C++ proposals that may switch threads necessarily means that the compiler would have to take this into account when those proposals should become part of the standard. The other way this could play out is that the standard simply makes using thread-specific state undefined for those threads of execution that can use these proposals. Overall, I think it may be useful to experiment with a command line switch or something like that, primarily to assess how big the performance degradation would be caused by having the compiler assume that threads can switch on function calls. (In reply to Jakub Jelinek from comment #14) > Even if we have an option that avoids CSE of TLS addresses across function > calls (or attribute for specific function), what would you expect to happen > when user takes address of TLS variables himself: > __thread int a; > void > foo () > { > int *p = &a; > *p = 10; > bar (); // Changes threads > *p += 10; > } I think that p would point to the initial thread's TLS, even after bar(). The user would be wrong to assume that it still is the initial thread's object "a" after having called bar().