[cfe-dev] RFC: __atomic_* support for gcc 4.7 compatibility
richard at metafoo.co.uk
Tue Apr 10 15:25:47 PDT 2012
On Tue, Apr 10, 2012 at 2:25 PM, David Chisnall <csdavec at swan.ac.uk> wrote:
> On 10 Apr 2012, at 22:11, Richard Smith wrote:
> > On Tue, Apr 10, 2012 at 12:58 PM, David Chisnall <theraven at sucs.org>
> > On 10 Apr 2012, at 20:22, Richard Smith wrote:
> > > Hi,
> > >
> > > I'm looking into adding support for gcc 4.7's __atomic_* builtins for
> the clang 3.1 release (these are necessary to support various parts of
> libstdc++4.7). Our current set of __atomic_* builtins is incompatible with
> gcc 4.7's builtins in a few ways:
> > While it would be nice to build libstdc++, it should be noted that the
> gcc builtins are poorly designed in a number of ways and I don't think we
> should be encouraging their use by supporting them in anything other than
> the specific case of supporting libstdc++.
> > I agree, but I think this is a problem of documentation. On that
> subject, do we have documentation for our current __atomic_ builtins
> The documentation is the C11 spec. The builtins have a 1:1 correspondence
> with the C11 generic functions in stdatomic.h.
The C11 spec does not talk about __atomic_*. A statement in our
documentation saying that these builtins implement the <stdatomic.h>
operations of the same name would be useful (especially since our builtins
have the same name as, but different behaviour from, the GCC builtins).
> I would strongly oppose supporting using the builtins with types that are
> not _Atomic-qualified, because doing so makes it trivial to introduce a
> large number of very subtle bugs.
> > Such support is necessary to support libstdc++'s <atomic>. I think
> you've made a reasonable case that we should have two sets of builtins, a
> C11-style set (the current builtins) and a GCC-compatible set. To this end,
> I would strongly prefer for them to have different names, so that the
> trivial mapping of <stdatomic.h> names to builtins never accidentally uses
> the GCC-compatible builtins. Unfortunately, that seems to require renaming
> the C11-style builtins (unless someone has a better suggestion).
> I believe that it's possible to implement the GCC ones in a terms of the
> clang ones in a header, if they're required for libstdc++. If libstdc++ is
> the only consumer of them, then an <atomic> that did this and then
> #include_next'd the libstdc++ one might be a better solution.
I assume you're suggesting that we cast the argument from T* to _Atomic(T*)
prior to passing it into the builtin? That's ugly, but seems like it might
be workable if _Atomic(T) always has the same size and alignment as T. I
don't know if those properties hold, but I understand the intent of
_Atomic() was that they need not. (We would also need to ensure TBAA knows
that T and _Atomic(T) can alias.)
This approach, including the need to interpose in front of <atomic> and
<shared_ptr> (and any other user of the atomics builtins in libstdc++) and
detect whether we're about to include a header from libstdc++, seems
sufficiently fragile that I'm still in favour of introducing GNU-compatible
> > 3) Clang is missing the __atomic_*_n, __atomic_always_lock_free and
> __atomic_fetch_nand builtins.
> > The _n builtins actually do what the current clang ones do.
> > Functionally, yes, but the _Atomic check makes clang's implementations
> unusable for libstdc++, and the _n variants are
> > required to check that the argument type is a 1, 2, 4, 8 or 16-byte
> integer or pointer type.
> The latter requirement is not required by either C++11 or C11.
If we want to fully support the GNU-style atomics, we should implement them
correctly. (Naturally, if we're using your compatibility-shim approach, we
needn't worry about this.)
> > > My current plan is:
> > >
> > > For (1), add support for the gcc-style arguments, then port libc++
> over to them, then remove support for the current arguments.
> > Please don't.
> > Your objections thus far have not been strong enough, in my opinion, to
> justify abandoning libstdc++4.7 support for clang, nor to justify
> abandoning g++ support for libc++ (although naturally that will be Howard's
> choice). I'm not opposed to keeping the existing builtins too, as
> distasteful as it is to have two competing, and very similar, sets.
> I'm not opposing supporting libstdc++, but I am not convinced that
> introducing a set of poorly designed intrinsics is the correct way of doing
> it, especially since we would be forced to support them long-term.
I share your concern. On the other hand, we have a long history of
supporting gcc features, even when we think their design is questionable,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-dev