This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: Functions that are CSEable but not pure

From: Jason Merrill <jason at redhat dot com>
To: "Joseph S. Myers" <joseph at codesourcery dot com>
Cc: GCC <gcc at gcc dot gnu dot org>
Date: Wed, 03 Oct 2012 23:40:19 -0400
Subject: Re: Functions that are CSEable but not pure
References: <506C8B3F.9080303@redhat.com> <Pine.LNX.4.64.1210032300320.29871@digraph.polyomino.org.uk>

On 10/03/2012 07:06 PM, Joseph S. Myers wrote:

On Wed, 3 Oct 2012, Jason Merrill wrote:

My implementation of dynamic initialization of TLS variables as mandated by
the C++11 and OpenMP standards uses this idiom implicitly, so I'd really like
to be able to optimize away multiple calls.


I'd thought that dynamic initialization of TLS variables was supposed to
need ELF gABI, C++ ABI, binutils and glibc support as per Jakub's comment
in bug 27557 - have you found a way to avoid needing those, or are you
actually discussing something else?

Handling it via init-on-first-use avoids the need for ELF and binutils support. The interface needs to be specified in the C++ ABI, and I we want glibc support for strict correctness (as with __cxa_atexit), but the functionality can be implemented without it.

Jason

References:
- Functions that are CSEable but not pure
  - From: Jason Merrill
- Re: Functions that are CSEable but not pure
  - From: Joseph S. Myers

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]