https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116827
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to Francois-Xavier Coudert from comment #6) > (In reply to Jonathan Wakely from comment #5) > > > #if defined(__has_feature) && __has_feature(modules) > > > > This is a bug. If __has_feature is _not_ define, then __has_feature(modules) > > would not compile > > Definitely agree, I had missed that, thanks for highlighting it. Every year > some more examples crop up into the SDKs, and every year I report them. > > Reported the examples in macOS 15.0 SDK as FB15255066 > A copy of that report is available there: > https://gist.github.com/fxcoudert/1e3ed3470febf220a392152189c143a3 > > > It looks like the header now assumes that if __has_feature(modules) is > > true, then they're compiling with Clang. Which is not true because GCC > > supports __has_feature now. > > Before I report this to Apple, I want to have an opinion: Iain, what do you > think is the best fix there? Do we want to suggest Apple not bypass > USE_CLANG_TYPES on GCC? At this point (with no other evidence) it would seem to me to be best if clang-specific stuff used __clang__ in the tests (we do _not_ set that in GCC, whereas testing __GNUC__ needs other checks to disambiguate). We might well want to reconcile or add pp defines to match the clang ones if that is creating problems - but I'd expect the underlying types to be unchanged (since that's going to break ABI otherwise). It's not clear to me yet why the change has been made (sorry this is not probably very helpful)
