https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864
--- Comment #67 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #66) > (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. Indeed, not sure what caused the compiler explorer instance to report differently, I can't repeat now (for trunk or 7.x clang). > On the other side, if we fixinclude it, the fixincluded headers will be only > used for gcc and not clang, right, right, I don't see any mechanism at the moment for clang to use GCC's fixed includes (it could be forced with -isystem, I suppose - but that's the User's decision). > 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. The folks I'm hoping for comments from are travelling this week (or, I think, in one case on vacation) so perhaps we can wait a few more days for some conclusion before applying this (it needs to go on the branches too, I suppose).
