On Tue, May 15, 2018 at 12:50 PM, Jonathan Wakely <jwakely....@gmail.com> wrote: > 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.
Ok. I give up for the moment. I will continue without libstdc++, as building libstdc++-v3, even with --disable-hosted-libstdcxx in my case seems to require some workarounds (enable_dlopen=no in the configure script) and some headers that I don't have at the moment. Maybe I return to it at a later time. >>>> 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/ I thought that it would make a difference, but if it doesn't, maybe I can omit 'volatile'. >> 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)
