domi...@lps.ens.fr (Dominique Dhumieres) writes:
> On x86_64-apple-darwin10 The following tests:
>
> g++.dg/gomp/tls-5.C
> g++.dg/tls/thread_local-cse.C
> g++.dg/tls/thread_local-order*.C
> g++.dg/tls/thread_local*g.C
>
> fail with
>
> sorry, unimplemented: dynamic initialization of non-function-lo
On 10/05/2012 10:38 AM, Jason Merrill wrote:
On 10/05/2012 04:29 AM, Richard Guenther wrote:
Or if we have the extra indirection via a reference anyway, we could
have a pointer TLS variable (NULL initialized) that on the first access
will trap where in a trap handler we could then perform initia
On 10/09/2012 11:27 AM, Jason Merrill wrote:
FAIL: g++.dg/tls/thread_local7.C scan-assembler-not \\.data
I've changed this test to require native TLS.
FAIL: g++.dg/tls/static-1.C *
And I've fixed the compiler to not mess with thread_local wrappers on
this test, since it uses __thread.
Te
On Wed, Oct 10, 2012 at 04:16:03PM -0400, Jack Howarth wrote:
> On Wed, Oct 10, 2012 at 04:50:22PM +0200, Rainer Orth wrote:
> > Jack Howarth writes:
> >
> > >Have you tried a gcc trunk build on linux configured to use emutls
> > > instead
> > > of tls to confirm that this issue is really da
On Wed, Oct 10, 2012 at 04:50:22PM +0200, Rainer Orth wrote:
> Jack Howarth writes:
>
> >Have you tried a gcc trunk build on linux configured to use emutls
> > instead
> > of tls to confirm that this issue is really darwin-specific? These failures
> > might
> > also appear on sparc-sun-sola
domi...@lps.ens.fr (Dominique Dhumieres) writes:
> On x86_64-apple-darwin10 The following tests:
>
> g++.dg/gomp/tls-5.C
> g++.dg/tls/thread_local-cse.C
> g++.dg/tls/thread_local-order*.C
> g++.dg/tls/thread_local*g.C
>
> fail with
>
> sorry, unimplemented: dynamic initialization of non-function-l
Jack Howarth writes:
>Have you tried a gcc trunk build on linux configured to use emutls instead
> of tls to confirm that this issue is really darwin-specific? These failures
> might
> also appear on sparc-sun-solaris2.9 but we don't have recent gcc trunk
> testresults
> for that. Perhaps R
On Tue, Oct 09, 2012 at 09:13:06PM -0400, Jason Merrill wrote:
> On 10/09/2012 04:36 PM, Dominique Dhumieres wrote:
>> ==36994== Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd
>> ==36994==at 0x10001252D: free (vg_replace_malloc.c:430)
>> ==36994==by 0x1003B5CB2: emutls_d
On 10/09/2012 04:36 PM, Dominique Dhumieres wrote:
==36994== Address 0x1003cd2e0 is 16 bytes inside a block of size 536 free'd
==36994==at 0x10001252D: free (vg_replace_malloc.c:430)
==36994==by 0x1003B5CB2: emutls_destroy (in
/opt/gcc/gcc4.8p-192219/lib/libgcc_s.1.dylib)
Aha. So the
> >> FAIL: g++.dg/tls/thread_local3.C -std=gnu++11 execution test
> >> FAIL: g++.dg/tls/thread_local4.C -std=gnu++11 execution test
>
> These ought to work. Can you debug the problem?
Backtrace for thread_local4.C
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x1503 o
> These don't work because of the lack of alias support; that's why I put
> dg-require-alias in the tests. Do I need a different magic incantation?
I understand nothing about alias, weak, ... stuff, but from pr52945, if you need
weak-alias, then you have also to use
/* { dg-require-weak "" } */
On 10/09/2012 10:43 AM, Jack Howarth wrote:
On Tue, Oct 09, 2012 at 04:07:51PM +0200, Dominique Dhumieres wrote:
On x86_64-apple-darwin10 The following tests:
g++.dg/gomp/tls-5.C
g++.dg/tls/thread_local-cse.C
g++.dg/tls/thread_local-order*.C
g++.dg/tls/thread_local*g.C
fail with
sorry, unimpl
On Tue, Oct 09, 2012 at 04:07:51PM +0200, Dominique Dhumieres wrote:
> On x86_64-apple-darwin10 The following tests:
>
> g++.dg/gomp/tls-5.C
> g++.dg/tls/thread_local-cse.C
> g++.dg/tls/thread_local-order*.C
> g++.dg/tls/thread_local*g.C
>
> fail with
>
> sorry, unimplemented: dynamic initializa
On x86_64-apple-darwin10 The following tests:
g++.dg/gomp/tls-5.C
g++.dg/tls/thread_local-cse.C
g++.dg/tls/thread_local-order*.C
g++.dg/tls/thread_local*g.C
fail with
sorry, unimplemented: dynamic initialization of non-function-local thread_local
variables not supported on this target
In addit
On 10/05/2012 04:29 AM, Richard Guenther wrote:
Or if we have the extra indirection via a reference anyway, we could
have a pointer TLS variable (NULL initialized) that on the first access
will trap where in a trap handler we could then perform initialization
and setup of that pointer.
Interest
On 10/05/2012 04:41 AM, Jakub Jelinek wrote:
Unfortunately, that penalty is not only for thread_local vars with
ctors/dtors. There is some penalty even for using
extern thread_local int i;
int foo (void)
{
return i;
}
(as compared to extern __thread int i;), because we have to at least check
On Fri, Oct 05, 2012 at 10:29:54AM +0200, Richard Guenther wrote:
> I wonder if an implementation is conforming that performs non-local TLS
> variable inits at thread creation time instead (probably also would require
> glibc support)?
I think it is conforming, but not really doable, because of dl
On Thu, Oct 04, 2012 at 01:38:38PM -0400, Jason Merrill wrote:
> commit 18c01be0ec8b7a3cda6a16e86356e8e434c12f89
> Author: Jason Merrill
> Date: Thu Sep 20 16:00:08 2012 -0400
>
> Support C++11 thread_local destructors.
> libstdc++-v3/
> * libsupc++/cxxabi.h: Declare __cxa_threa
On Thu, Oct 4, 2012 at 7:38 PM, Jason Merrill wrote:
> Both C++11 and OpenMP specify that thread_local/threadprivate variables can
> have dynamic initialization and destruction semantics. This sequence of
> patches implements that.
>
> The first patch adds the C++11 thread_local keyword and imple
19 matches
Mail list logo
