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

[Howard Hinnant]

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_

Howard