https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #22 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Erik Schnetter from comment #21) > https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00162.html Additional to the comments on list. Perhaps this is just unfixable :( I suspect that Apple will want to re-release the SDK, and the best real fix is to use the SDK from the previous Xcode command line tools (you can still use the latest tools from XC10.2 - just install the older version somewhere and then use --with-sysroot= and/or --sysroot=) (a) there's no guarantee that _Atomic u_long has the same size or alignment as volatile u_long. C11: 6.2.5 Types ... 27 ... The size, representation, and alignment of an atomic type need not be the same as those of the corresponding unqualified type. ... .. although it *probably* is for simple types for which there are direct atomic ops. (b) If we hack around it with "volatile" (assuming that the type happens to have the same size and alignment), this will silently fail in any case it's used. (c) the <atomic> header is only available from C++11, AFAIR, and GCC is supposed to be boot-strappable with C++98. Iff Apple were to elect to declare that the OS *requires* C++11 to operate, then we should fix the configuration for Darwin to ensure that this is enforced. (d) In any case, is there any guarantee that the representation of the u_long as a C++ atomic is the same size and align as its C11 counterpart? (I've not checked this).
