On 2012-03-25 20:34, Martin Nowak wrote:
Sorry,
that might have been misleading.
The point I was trying to make is that D's TLS support shouldn't
deviate from the native platform TLS if one is available. I've just
tried it out, and indeed I can access C TLS variables from D.
Ok. Yes, if a nati
On Sun, 25 Mar 2012 16:29:25 +0200, Jacob Carlborg wrote:
On 2012-03-23 12:55, Martin Nowak wrote:
Just another point about TLS.
extern(C) /*__thread*/ int foo;
At some point you want to be able to access C++ TLS variables
so emulation should not replace native TLS support.
So C++ TLS is
On 2012-03-23 12:55, Martin Nowak wrote:
Just another point about TLS.
extern(C) /*__thread*/ int foo;
At some point you want to be able to access C++ TLS variables
so emulation should not replace native TLS support.
So C++ TLS is not using the same implementation as the C extension __thread
On 2012-03-23 06:03, Martin Nowak wrote:
On Mon, 19 Mar 2012 10:40:25 +0100, Jacob Carlborg wrote:
As I understand it, in the native ELF implementation, assembly is used
to access the current module id, this is for FreeBSD:
http://people.freebsd.org/~marcel/tls.html
This is how ___tls_get_addr
On 3/25/2012 5:10 AM, Manu wrote:
Are there work arounds if I should happen to run in to this? GDC is
currently the only win64 compiler. I'm putting a lot of faith it in for
the time being.
Until it's found why it happens, I can't say how to avoid it. Roughly I
think it may be related to the
On 25 March 2012 05:55, Daniel Green wrote:
> On 3/24/2012 8:35 PM, Manu wrote:
> > Cheers for the info. Here's hoping the release works out well.
> > What instabilities are you primarily concerned about with the existing
> > release? I've been using it for a couple of weeks, and had no problems.
