https://issues.dlang.org/show_bug.cgi?id=15523
--- Comment #7 from Manu <[email protected]> --- (In reply to Jacob Carlborg from comment #6) > (In reply to Manu from comment #4) > > I would suggest that since 'thread_local' is C++11 standard, then that > > should be the one. > > That would be a breaking change. How? We have no support at all right now... there's nothing to break? > > Since '__thread' is not standard, I imagine it would be best supported by > > GDC(/Clang?) via the @attribute("__thread") mechanism that they support for > > their compiler-specific attributes. > > thread_local is not supported by the version of Clang supplied by Apple. The > one most likely installed. For real? How old is that compiler? That still doesn't change that it's non-standard, and I would reserve default behaviour for the standard keyword, which I'm astonished isn't in the Clang release. ** google reveals a lot of people also complaining that __thread doesn't work on Apple compilers either. > > extern(C++): > > > > // Standard: > > extern int i; // thread_local > > > > // GCC(/Clang?): > > @attribute("__thread") extern int i; // __thread (this is probably very easy > > for those toolchains to implement) > > DMD need to be able to handle it as well. Perhaps through a pragma? > > This would only affect extern(C++)? Would it be confusing to need to specify > @attribute("__thread") only when the linkage is C++? I don't really think so; __thread is a C++ attribute, so I think it only makes sense if you extern(C++) aswell. > I found this stackoverflow thread explaning the different sematnics of > __thread and thread_local [1]. It looks like if you use thread_local for any > use case that __thread is valid, it will behave the same, except when it's > declared "extern". > > [1] > http://stackoverflow.com/questions/13106049/c11-gcc-4-8-thread-local- > performance-penalty Yeah, I saw the same article. My guess was that the extern case generates a function call such that they can change the ABI if they like. Doesn't seem like a problem to me, and actually, should make it really easy to implement! Just lower to a little stub with the proper mangled name. --
