[cfe-dev] RFC: __atomic_* support for gcc 4.7 compatibility

[Chandler Carruth]

On Wed, Apr 11, 2012 at 1:03 AM, Howard Hinnant <hhinnant at apple.com> wrote:

> On Apr 10, 2012, at 7:59 PM, Howard Hinnant wrote:
>
> > On Apr 10, 2012, at 7:24 PM, Chandler Carruth wrote:
> >
> >> I want to call out this point:
> >>
> >> On Wed, Apr 11, 2012 at 12:25 AM, Richard Smith <richard at metafoo.co.uk>
> wrote:
> >> 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
> builtins.
> >>
> >> I think this is setting ourselves up for an endless game of catchup.
> What is worse, our users will suffer.
> >>
> >> Version skew between libstdc++ and Clang is inevitable. As a
> consequence, the advantages of being maximally compatible with libstdc++
> are only present when we can be largely *forward* compatible. This seems
> impossible if we have to intercept ever header to reference a GCC builtin
> and introduce our wrapper for it.
> >>
> >>
> >> At a fundamental level, I am not yet comfortable with Clang, after
> defining __GNUC__ and acting as a heavily compatible compiler with GCC,
> going on to define builtin functions which share the same name but
> incompatible semantics with GCC builtins. This seems like a recipe for a
> long string of puzzling compilation failures, user frustration, and impeded
> adoption of Clang.
> >>
> >> I think we should continue with the long standing policy of, when
> reasonable and tenable, supporting the GCC builtins with their names, and
> allowing users to not care. Then, under a *different* naming pattern, and
> guarded by proper __has_feature macros etc, we should provide
> Clang-specific extensions which have the semantics we would rather see.
> >>
> >> While a realize this isn't ideal, and it requires renaming currently
> supported intrinsics I see few options left to us:
> >> 1) We haven't released with these intrinsics
> >> 2) GCC has released with its intrinsics
> >> 3) We failed to discuss our intrinsics sufficiently with the GCC folks
> to get them to implement the same set
> >> 4) GCC folks failed to discuss theirs with us sufficiently to get us to
> implement the same set
> >> 5) We need something for Clang v3.1, or it is instantly un-usable with
> GCC 4.7 and later.
> >>
> >> I don't like any of this, and it isn't how I would wish for things to
> proceed if I had it to do again, but this is where we are. We need to
> realize that, today, I cannot compile any meaningful C++98 code with the
> default C++ standard library on Linux (after a distro picks up GCC 4.7) and
> Clang. I do not think that is an acceptable state to release Clang under.
> >
> > Perhaps we need to stake out another namespace for clang atomic
> intrinsics.  Our current prefix is:
> >
> > __atomic_
> >
> > Suggestions:
> >
> > __clang_atomic_
> > __clng_atmc_
> > _ClangAtomic_
> > _CLNGatomic_
> > _CLNG_ATM_
> > _ClngAtm_
> >
> > The final suggestion has the same length as our current prefix.
>
>
> Or even shorter: :-)
>
> __atomx_
>

I am quite lazy when it comes to typing, but perhaps here is not the time
to save characters. ;] I would vote:

__clang_atomic_

or, based on the discussion between David and Richard, perhaps:

__c11_atomic_

to call out their close correspondance with the c11 spec.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120411/7c5b0a2b/attachment.html>