On 5 December 2016 at 11:34, Mehdi AMINI via Phabricator < revi...@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 > > > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
