[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

[schnetter at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #25 from Erik Schnetter <schnetter at gmail dot com> ---
> On Thu, Apr 4, 2019 at 5:43 AM iains at gcc dot gnu.org <
> gcc-bugzilla@gcc.gnu.org> wrote:
>
> > 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.
> >
>
> This is for Apple systems, where they presumably control the ABI, or are
at
> least aware of the ABI when writing header files.
>
> (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.
> >
>
> _Atomic is used only in a single struct, which is marked "this structure
> should not be used outside the kernel", and protected by a "#ifdef
> __APPLE_API_UNSTABLE" (which unfortunately defaults to being defined). To
> my knowledge, no part of GCC will use this structure.
>
> (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.
> >
>
> The header file works for all versions of C and C++. It uses _Atomic for
> C11, _Atomic for C++11 (the bug we're seeing), and volatile in all other
> cases. There is no requirement for C++11.
>
> (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).
> >
>
> This seems to be an ABI question, and I assume Apple checked this on their
> ABIs (probably only Intel and ARM). I assume that this is generally the
> case as C11 and C++11 atomics were designed at the same time, so the ABI
> designers will want to ensure sure.
>
> -erik