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

[Hal Finkel]

On Tue, 10 Apr 2012 20:54:30 -0400
Seth Cantrell <seth.cantrell at gmail.com> wrote:

> Calling out the correspondence with the C11 spec with __c11_atomic_
> does seem desirable.

I agree. Another alternative is to just use __builtin_.

 -Hal

 Also maybe it's better for adoption by gcc as
> well, if they choose to add builtins that correspond to C11?
> 
> On Apr 10, 2012, at 8:08 PM, Chandler Carruth wrote:
> 
> > 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.
> > _______________________________________________
> > cfe-dev mailing list
> > cfe-dev at cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> 



-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory