[PATCH] D26376: Undef stdatomic.h macro definitions that are defining functions provided in libc++ <atomic>

[Richard Smith via cfe-commits]

On 5 December 2016 at 11:34, Mehdi AMINI via Phabricator <
reviews at reviews.llvm.org> wrote:

> mehdi_amini added a comment.
>
> In https://reviews.llvm.org/D26376#597614, @mclow.lists wrote:
>
> > More info - The following code:
> >
> >   #include <stdatomic.h>
> >   int main () {}
> >
> >
> > fails to compile on either gcc 6.2 (locally), gcc 7 head (online
> compiler) or MSVC (online compiler).
>
>
> Interesting, that lead me to https://gcc.gnu.org/bugzilla/
> show_bug.cgi?id=60932 which describes the issue I believe.
>
> One of the example is that we should guarantee ABI compatibility between C
> and C++ for such code:
>
>   #ifdef __cplusplus
>   #include <atomic>
>   using namespace std;
>   #else
>   #include <stdatomic.h>
>   #endif
>
>   struct s {
>     atomic_int i;
>   };
>
> Do you know if we're providing this guarantee today?


If by "we" you mean libc++, then yes, it does everything it can to provide
this guarantee -- its atomic<T> is a wrapper around an _Atomic(T).

If by "we" you also include Clang, and you include the case where <atomic>
is the libstdc++ version, then results are more mixed -- GCC and libstdc++
made some very poor decisions early on regarding the size and alignment of
atomic<T> for some types T (such as char[3]), and Clang's _Atomic(T) /
<stdatomic.h> does not replicate those poor choices. If I remember
correctly, this is fixed in more recent versions of libstdc++.

In https://reviews.llvm.org/D26376#613186, @EricWF wrote:
>
> > Yeah this seems like a configuration that simply can't be supported. I'm
> not sure if this patch is a great idea.
>
>
> OK, let's abandon this then!
>
>
> https://reviews.llvm.org/D26376
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161205/5ccd5c34/attachment-0001.html>