Implementing C++1x and C1x atomics

["Joseph S. Myers" <joseph at codesourcery dot 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<hans.boehm@hp.com> 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
joseph@codesourcery.com