https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to John Marshall from comment #4) > (In reply to comment #3) > > > --- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> --- > > > * for the other things, if it's a beta, then perhaps there's some chance > > > it > > > will be fixed before issue. > > > > Right: I believe I got at least one such bug fixed during 10.14 Beta. > > FWIW I've reported the AvailabilityInternal.h part to Apple (as FB6125120), > though I'm just some rando on the internet so they probably haven't even > read it yet. With a few dozen more duplicate reports they might look into > it... :-) (See https://twitter.com/jomarnz/status/1136275996515155969 and > thread.) thanks, AFAIU they are somewhat driven by radars for fixing things - so it's worth doing. > > > > * we > > > - unconditionally define __has_xxxxxx(x) 0 in Darwin's builtin defines > > > > That's most likely the easiest way out. > > I don't think that'll help the AvailabityInternal.h problem as presumably > these things are already decaying to 0, leading to a path through > AvailabityInternal.h that never defines __AVAILABILITY_INTERNAL__MAC_10_14 > et al. So predefining them to 0 will lead to the same path, no? let's not speculate ... could you (and/or Rainer) try this (untested) patch and see how far it gets you? (I don't expect it to solve all problems, but maybe some - it also might create some by introducing the false assumption that the reports about builtins/extensions are valid). diff --git a/gcc/config/darwin-c.c b/gcc/config/darwin-c.c index aa5d2f2..9440b30 100644 --- a/gcc/config/darwin-c.c +++ b/gcc/config/darwin-c.c @@ -731,6 +731,13 @@ darwin_cpp_builtins (cpp_reader *pfile) builtin_define_with_value ("__ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__", macosx_version_as_macro(), false); + /* Until we implement __has-builtin, __has_feature, __has_extension it's + better to jam them to 0 than to fight the cases where system headers + have not been tested with GCC. */ + builtin_define_with_value ("__has_builtin(X)", "0", false); + builtin_define_with_value ("__has_feature(X)", "0", false); + builtin_define_with_value ("__has_extension(X)", "0", false); + /* Since we do not (at 4.6) support ObjC gc for the NeXT runtime, the following will cause a syntax error if one tries to compile gc attributed items. However, without this, NeXT system headers cannot be parsed > >> - implement __has_xxxxx() .. which would be nicer, but not sure who has > >> time > >> to do it .. > > I've been feeling some temptation to implement > __attribute__(availability(...)) as a no-op that just ignores its arguments. > It would be preferable for Apple to put the fallback definitions back into > their header, but failing that capitulating to __availability__ seems > least-worst. I'm not in favour of defining that to "do nothing" (actually a "do nothing" attribute patch is only a few lines) - I suspect defining it to "do nothing" would open a different can of worms - at least the absence of something is a known state to Apple - and reasonably can be made to operate conservatively. I have an implementation for __attribute__(__unavailable__) on my gcc-5 branch, it needs bringing forward (and get accepted onto trunk) - at that point, it's probably not too hard to implement the availability attribute.
