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

[Howard Hinnant]

It looks like we have a couple of questions:

1.  Does clang support libstdc++ <atomic>?

2.  Does libc++ <atomic> support gcc?

I have no opinion on 1.  I will leave that to the clang developers.

On 2, I have no motivation to support gcc.  gcc has its own std::lib solution and the GPL is not compatible with libc++ licensing.  However if there are members of this community that wish to support gcc (and wish to do the work to make it so), and if there is zero run time and code size overhead, and if the compile time overhead is negligible, I have no objection.  I will cringe at the ugliness it will introduce to the source, but I can live with that.

Since I do not care about gcc compatibility, I prefer whatever intrinsics have the most seamless matching to C11/C++11.  I'm under the impression that this is the current clang design, but I am not expert in this area.

I do not understand the need for __atomic_init.  The atomic constructors that currently look like:

    /*constexpr*/ __atomic_base(_Tp __d) { __atomic_store(&__a_, __d, memory_order_seq_cst); }

used to look like:

   /*constexpr*/ __atomic_base(_Tp __d) : __a_(__d) {}

and it is my understanding that the latter is correct.

If the latter has the correct semantics, I prefer it to:

   /*constexpr*/ __atomic_base(_Tp __d)  {__atomic_init(&__a_, __d);}

An intrinsic that does nothing but initialize the same way a C/C++ statement would do, adds no value, but does add confusion over what it is doing.  If __atomic_init does add needed functionality, then of course I would agree that we need it.

David, could you revert the initialization statements to use either plain C++, or the __atomic_init intrinsic?

<atomic> also needs to be treated with constexpr and noexcept, although there is no rush to do that prior to having the intrinsics fully operational (or are they already?).

Thanks,
Howard