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

[Chandler Carruth]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120411/d9552815/attachment.html>