On Tue, May 15, 2018 at 12:27 AM, Jonathan Wakely <jwakely....@gmail.com> wrote: > On 14 May 2018 at 22:32, Rodrigo V. G. <rodr...@gmail.com> wrote: >> In addition to the bug: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60932 >> I wanted to add some comment: >> >> It would be very useful if the _Atomic keyword would be supported in C++. >> This way the <stdatomic.h> header could be included inconditionally in C++ >> code. >> Even if it is not compatible with the C++ <atomic> header, it would be >> useful. >> >> Supporting the _Atomic keyword in C++ would benefit at least two cases: >> >> - When mixing C and C++ code for interoperability (using, in C++, some >> variables declared as _Atomic in a C header). >> >> - When developing operating systems or kernels in C++, in a >> freestanding environment (cross compiler), <atomic> is not available, > > Why not? It's part of a freestanding C++ implementation.
When building a cross compiler as indicated in: https://wiki.osdev.org/GCC_Cross-Compiler#GCC it does not install the <atomic> header. >> but <stdatomic.h> is. > > How? It's not part of any C++ implementation at all, freestanding or not. As far as I can see the <stdatomic.h> can be included from C++ code (also in the cross compiler). Only that it complains about _Atomic and _Bool so it does not work. So _Atomic and _Bool seem to be the missing pieces. >> So to correctly use things like __atomic_fetch_add in C++ in >> freestanding mode, this is the only way. Otherwise one cannot use >> atomics at all in these conditions. > > Why can't you use __atomic_fetch_add directly? I tried to use __atomic_fetch_add in C++ with a volatile (non _Atomic) variable, and it seems to generate the same assembler code. The only difference that I saw was that with _Atomic it generates a "mfence" instruction after initialization but with volatile it does not. So I think it might not provide the same guarantees. (Sorry, I forgot to cc the list, now I do cc)
