https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531
--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> ---
* thanks for looking at this! (my machines are all tied up right now, so any
testing won't happen before 'tomorrow')
* apologies if this comes across as negative - but TBH I'm a bit nervous about
applying something like this without wider testing - certainly full reg-straps
on affected systems.
* A visual inspection of the patch, suggests it might be disabling more than is
necessary - GCC has attributes "available" and "deprecated" - it's only
"unavailable" that's currently missing [I have a patch for that somewhere, will
have to dust it off for 10]. (deprecated_with_replacement could be implemented
in terms of deprecated with message).
* I did not need any patch to bootstrap open branches [7, 8, and trunk] on
10.13.6 (in fact, not on any Darwin that supports libsanitizer - bearing in
mind that upstream doesn't support 10.6 now).
* GCC5 is closed, so any patch we might have would be something applied
"locally" to any private branches.
* The underlying issue is that there are a number of problems with system
headers [e.g. missing guards for __has_feature(), missing guards for block
syntax, nullability and lightweight generics, the latter two especially an
issue for objective c]. The problems tend to be dependent on the SDK version,
which is unfortunate because typically one could target 10.13 from 10.14 using
the 10.14 SDK, so the target OS version is not a 100% reliable test (TODO:
investigate whether there's an SDK version that we can easily pick up).
* for tests where there are a large number of problems (e.g. the objective c
stuff in particular, where there are no easy work-arounds), it's my plan to
cook up some proxy headers to allow us to continue to test what *does* work.
* from my investigations, it seems that the underlying issue can be solved by
including the relevant headers (but because of the points above "relevant
headers" depends on the SDK version). So, it might be that there' a small
number of tests for which a workaround will be better.. e.g at present, I have
the following to fix the test
diff --git a/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
b/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
index b2def1e858..7c08ef9c91 100644
--- a/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
+++ b/gcc/testsuite/g++.dg/other/darwin-cfstring1.C
@@ -6,6 +6,12 @@
/* { dg-do compile { target *-*-darwin* } } */
/* { dg-options "-ftrack-macro-expansion=0 -mconstant-cfstrings" } */
+#if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101300
+# include <CoreFoundation/CoreFoundation.h>
+#elif __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ >= 101000
+# include <CoreFoundation/CFAvailability.h>
+#endif
+
#include <CoreFoundation/CFString.h>
#ifdef __CONSTANT_CFSTRINGS__
