This is the mail archive of the
mailing list for the glibc project.
Implementing C++1x and C1x atomics
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Richard Guenther <richard dot guenther at gmail dot com>
- Cc: "Boehm, Hans" <hans dot boehm at hp dot com>, Andrew Haley <aph at redhat dot com>, Paolo Bonzini <bonzini at gnu dot org>, gcc at gcc dot gnu dot org, libc-alpha at sourceware dot org
- Date: Wed, 12 Aug 2009 19:46:19 +0000 (UTC)
- Subject: Implementing C++1x and C1x atomics
- References: <4A82E93B.email@example.com> <Pine.LNX.firstname.lastname@example.org> <4A82F34B.email@example.com> <4A82F47A.firstname.lastname@example.org> <4A82F5C0.email@example.com> <4A82F88D.firstname.lastname@example.org> <238A96A773B3934685A7269CC8A8D042577A01E71A@GVW0436EXB.americas.hpqcorp.net> <238A96A773B3934685A7269CC8A8D042577A01E754@GVW0436EXB.americas.hpqcorp.net><email@example.com>
(moved from gcc-patches to gcc and libc-alpha)
On Wed, 12 Aug 2009, Richard Guenther wrote:
> On Wed, Aug 12, 2009 at 8:24 PM, Boehm, Hans<firstname.lastname@example.org> wrote:
> > [Partially replying to myself]
> >> From: ?Boehm, Hans
> >> At the risk of asking a stupid question, shouldn't all the
> >> code inside gcc gradually migrate towards using the C++0x
> >> (and probably C1x) atomics, which seem to be generally
> >> supported by gcc 4.4?
> >> There are known issues with __sync (no atomic loads and
> >> stores, underspecified ordering), which is why there wasn't
> >> much of an effort topush the __sync interface into C++0x.
> >> Hans
> > OK. ?That was largely a stupid question, since we're talking about the
> > compiler implementation of those primitives, which presumably are
> > shared with the atomic<T> implementation?
> I'm not aware of a proper implementation of the C++1x atomics or the memory
> model for gcc.
And a proper implementation would sure have underlying built-in functions,
added to the __sync_* set.
The C1x atomics specification
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1349.htm> does not
mention any amendment to the list of headers to be provided by
freestanding implementations (clause 4 paragraph 6), which suggests that
providing this header is actually in the domain of libc, not the compiler
(which accords with it providing (generic) library functions, which the
headers for freestanding implementations do not). It seems clear however
that close cooperation with the compiler will be needed in the
implementation to ensure that the right semantics are available from the
compiler for the header to use.
The information the compiler should provide the library would include
which operations are available built-in or in libgcc and which the C
library has to emulate with locks (if e.g. a particular architecture or
subarchitecture does not have 64-bit atomic operations). Given how many
variations there are on what targets support and how, and given that
what's supported may depend on -march etc. options passed when compiling
code that includes the header, I think a single version of the header for
all targets, that contains code conditional on various predefined macros,
would be a good ideal to aim for.
The compiler would also need to meet the underlying memory model
requirements - avoiding optimizations that break the memory model
assumptions (writes to locations that may not be written in the memory
model, in particular) unless given an option to say it doesn't need to
follow the model.
Joseph S. Myers