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

Jacob Carlborg <doob@me.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doob@me.com

--- Comment #1 from Jacob Carlborg <doob@me.com> ---
I'm not sure if there's any different between thread_local and __thread. But for __thread there's no specific mangling, at least not on OS X.

Have you tried and see what happens? Unfortunately I cannot do that on OS X, since neither thread_local is supported (__thread works though) and the D implementation of TLS on OS X is not compatible with the C implementation.

--

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

--- Comment #2 from Manu <turkeyman@gmail.com> ---
Wow, you seem to be right, 'thread_local' doesn't appear to affect the mangling... that's astonishing! Surely that can only lead to really-hard-to-track link related bugs...

Okay, well then, the question is, can we support C++ 'thread_local' semantics for extern(C++) of non-__gshared?

--

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

--- Comment #3 from Jacob Carlborg <doob@me.com> ---
(In reply to Manu from comment #2)

> Okay, well then, the question is, can we support C++ 'thread_local' semantics for extern(C++) of non-__gshared?

As with everything, it's just a matter of someone implementing it. Although, if "__thread" and "thread_local" have different semantics, I wonder what syntax to use in D then.

// foo.cpp

__thread int a;
thread_local int b;

// foo.d

extern(C++) extern int a; // this will have the semantics of __thread
extern(C++) extern /* __thread_local ? */ int b; // what should this syntax be?

--

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

--- Comment #4 from Manu <turkeyman@gmail.com> ---
I would suggest that since 'thread_local' is C++11 standard, then that should be the one.

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.

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)

--

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

--- Comment #5 from Manu <turkeyman@gmail.com> ---
(In reply to Manu from comment #4)
>
> // GCC(/Clang?):

** GDC(/LDC)

;)

--

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

--- Comment #6 from Jacob Carlborg <doob@me.com> ---
(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.

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

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

--

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

--- Comment #7 from Manu <turkeyman@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.

--

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

--- Comment #8 from Manu <turkeyman@gmail.com> ---
(In reply to Manu from comment #7)
> (In reply to Jacob Carlborg from comment #6)
> >
> > 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.

Then again, __thread specifies only an ABI and no functions or mangling, so it could theoretically apply to D variables just as readily as extern(C++).

thread_local only really makes sense for extern(C++) though, and that's what
I'm concerned with here.
I think it makes good sense that non-__gshared extern(C++) should follow the
standard, and I'm sure Apple will come to the party before too long.

--

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

--- Comment #9 from Jacob Carlborg <doob@me.com> ---
(In reply to Manu from comment #7)

> How? We have no support at all right now... there's nothing to break?

Hmm, yeah. I kind of assumed it already worked, at least for built-in types, like int.

> For real? How old is that compiler?

Xcode 7.2 was released Dec 8, 2015.

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

__thread is supported, but not thread_local. See this stackoverflow post [1] explaining why. Something about ABI compatibility.

> ** google reveals a lot of people also complaining that __thread doesn't work on Apple compilers either.

It's supported since OS X 10.7, quite old by now.


> I don't really think so; __thread is a C++ attribute, so I think it only makes sense if you extern(C++) aswell.

You mean "thread_local"?

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

Yeah, as long as you know how the compiler works ;)

[1] http://stackoverflow.com/a/29929949

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |C++
                 CC|                            |bugzilla@digitalmars.com

--