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
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-local
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.
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_destroy
Jack Howarth howa...@bromo.med.uc.edu 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
On Wed, Oct 10, 2012 at 04:50:22PM +0200, Rainer Orth wrote:
Jack Howarth howa...@bromo.med.uc.edu 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
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 howa...@bromo.med.uc.edu writes:
Have you tried a gcc trunk build on linux configured to use emutls
instead
of tls to confirm that this issue
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
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,
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 } */
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 of
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
On Thu, Oct 4, 2012 at 7:38 PM, Jason Merrill ja...@redhat.com 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
On Thu, Oct 04, 2012 at 01:38:38PM -0400, Jason Merrill wrote:
commit 18c01be0ec8b7a3cda6a16e86356e8e434c12f89
Author: Jason Merrill ja...@redhat.com
Date: Thu Sep 20 16:00:08 2012 -0400
Support C++11 thread_local destructors.
libstdc++-v3/
* libsupc++/cxxabi.h: Declare
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
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
16 matches
Mail list logo
