[Issue 15523] extern(C++) support TLS (C++ 'thread_local') linkage?

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=15523

--- Comment #7 from Manu <turkeyman at gmail.com> ---
(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.

--