This solved compiling:
#include <stdatomic.h> #include <atomic>
Differential D26376
Undef stdatomic.h macro definitions that are defining functions provided in libc++ <atomic> mehdi_amini on Nov 7 2016, 4:23 PM. Authored by
Details
Diff Detail
Event TimelineComment Actions Hmm, this won't help when building libc++ as a module, and we don't have a wrapper header to hold these undefs since <stdatomic.h> is not part of c++. So either that combination of includes gives a broken <atomic> or a broken <stdatomic.h>, or we do something nonstandard like reimplementing the latter in terms of the former in libc++. Eric, Marshall, what do you think? How / how much should we support this non-c++ header? Comment Actions Ok - looking just at kill_dependency, this was added to the C standard in C11. It's required to be a macro. I see that Bionic (sometimes) defines atomic_is_lock_free as a macro. Comment Actions 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). Comment Actions Yeah this seems like a configuration that simply can't be supported. I'm not sure if this patch is a great idea. Comment Actions 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? OK, let's abandon this then! Comment Actions This is the wrong approach. C and C++ compatibility is far more important than taking the easy way out. By doing this, you're potentially breaking the ABI for all software that relies on atomic operations... |