On 15 May 2018 at 11:01, Rodrigo V. G. <rodr...@gmail.com> wrote: > 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.
That's not a problem with GCC, that's a problem with those instructions. If you want a freestanding C++ implementation then configure GCC with --disable-hosted-libstdcxx and build+install libstdc++. Those instructions do neither of those things, so it's unsurprising you don't get a proper freestanding C++ implementation. >>> 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 you're saying it can be included, it just doesn't work. Great! That's true for this header too: #error "This header doesn't compile" >>> 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. Why use volatile? http://isvolatileusefulwiththreads.com/ > 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)