https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #66 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Iain Sandoe from comment #62) > (In reply to Iain Sandoe from comment #61) > > (In reply to Jonathan Wakely from comment #60) > > > PR 81797 was the relevant bug, which apparently is still present for > > > darwin > > > when using the buggy new APFS filesystem > > > > so, from discussion on IRC, and notes above, this seems to be a known issue > > (with AFPS only) and the current remedy is to continue the bootstrap. > > > > Let's consider that we have a viable work-around and then please can we wait > > for a response from Apple and the clang devs before making a final fix? > > > > (i.e. this is enough of a work-around to prevent folks from being blocked > > right now) > > BTW if you look at > https://godbolt.org/z/7nwoLN > and flip between C and C++, you will see that clang++ is not generating the > same code for _Atomic int x, as clang (C). Trying clang vs. clang++ (7.0.1) on _Atomic int a = 4; void foo () { a++; } (admittedly on x86_64-linux), I get the same generated code with C and C++, except for the mangling of the function, so it seems _Atomic is not ignored. On the other side, if we fixinclude it, the fixincluded headers will be only used for gcc and not clang, right, so the condition I wrote should be sufficient. If the fixincluded headers would be also used by clang, then we might want to add && !defined(__clang__) to that.
