[PATCH] Darwin: Future-proof -mmacosx-version-min
f18cbc1ee1f4 (2021-12-18) updated various parts of gcc to not impose a Darwin or macOS version maximum of the current known release. Different parts of gcc accept, variously, Darwin version numbers matching darwin2*, and macOS major version numbers up to 99. The current released version is Darwin 21 and macOS 12, with Darwin 22 and macOS 13 expected for public release later this year. With one major OS release per year, this strategy is expected to provide another 8 years of headroom. However, f18cbc1ee1f4 missed config/darwin-c.c (now .cc), which continued to impose a maximum of macOS 12 on the -mmacosx-version-min compiler driver argument. This was last updated from 11 to 12 in 11b967577483 (2021-10-27), but kicking the can down the road one year at a time is not a viable strategy, and is not in line with the more recent technique from f18cbc1ee1f4. Prior to 556ab5125912 (2020-11-06), config/darwin-c.c did not impose a maximum that needed annual maintenance, as at that point, all macOS releases had used a major version of 10. The stricter approach imposed since then was valuable for a time until the particulars of the new versioning scheme were established and understood, but now that they are, it's prudent to restore a more permissive approach. gcc/ChangeLog: * config/darwin-c.cc: Make -mmacosx-version-min more future-proof. Signed-off-by: Mark Mentovai --- gcc/config/darwin-c.cc | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/gcc/config/darwin-c.cc b/gcc/config/darwin-c.cc index 9203c84d2c26..00fc1253e265 100644 --- a/gcc/config/darwin-c.cc +++ b/gcc/config/darwin-c.cc @@ -691,7 +691,8 @@ macosx_version_as_macro (void) if (!version_array) goto fail; - if (version_array[MAJOR] < 10 || version_array[MAJOR] > 12) + /* clang accepts up to 99. */ + if (version_array[MAJOR] < 10 || version_array[MINOR] > 99) goto fail; if (version_array[MAJOR] == 10 && version_array[MINOR] < 10) -- 2.36.1
[PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK
The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
contain this definition in :
863 #define __null_terminated
This collides with the use of __null_terminated in libstdc++'s
experimental fs_path.h.
As libstdc++'s use of this token is entirely internal to fs_path.h, the
simplest workaround, renaming it, is most appropriate. Here, it's
renamed to __nul_terminated, referencing the NUL ('\0') value that is
used to terminate the strings in the context in which this tag structure
is used.
libstdc++-v3/ChangeLog:
* include/experimental/bits/fs_path.h: Rename __null_terminated
to __nul_terminated avoid colliding with a macro in Apple's SDK.
Signed-off-by: Mark Mentovai
---
libstdc++-v3/include/experimental/bits/fs_path.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libstdc++-v3/include/experimental/bits/fs_path.h
b/libstdc++-v3/include/experimental/bits/fs_path.h
index b0825ba76e80..19d246100cb5 100644
--- a/libstdc++-v3/include/experimental/bits/fs_path.h
+++ b/libstdc++-v3/include/experimental/bits/fs_path.h
@@ -140,10 +140,10 @@ namespace __detail
inline _Source
_S_range_begin(_Source __begin) { return __begin; }
- struct __null_terminated { };
+ struct __nul_terminated { };
template
-inline __null_terminated
+inline __nul_terminated
_S_range_end(_Source) { return {}; }
template
@@ -459,11 +459,11 @@ namespace __detail
struct _Cvt;
static string_type
-_S_convert(value_type* __src, __detail::__null_terminated)
+_S_convert(value_type* __src, __detail::__nul_terminated)
{ return string_type(__src); }
static string_type
-_S_convert(const value_type* __src, __detail::__null_terminated)
+_S_convert(const value_type* __src, __detail::__nul_terminated)
{ return string_type(__src); }
template
@@ -477,7 +477,7 @@ namespace __detail
template
static string_type
- _S_convert(_InputIterator __src, __detail::__null_terminated)
+ _S_convert(_InputIterator __src, __detail::__nul_terminated)
{
auto __s = _S_string_from_iter(__src);
return _S_convert(__s.c_str(), __s.c_str() + __s.size());
@@ -504,7 +504,7 @@ namespace __detail
template
static string_type
- _S_convert_loc(_InputIterator __src, __detail::__null_terminated,
+ _S_convert_loc(_InputIterator __src, __detail::__nul_terminated,
const std::locale& __loc)
{
const std::string __s = _S_string_from_iter(__src);
--
2.36.1
Re: [PATCH] libstdc++: Rename __null_terminated to avoid collision with Apple SDK
Thanks, Jonathan. I am, in fact, so certifying.
I do believe that bringing up support for new OS versions is in scope for
open branches, and it makes sense to merge, particularly for a trivial and
uncontentious patch like this one.
Jonathan Wakely wrote:
> On Fri, 10 Jun 2022 at 21:12, Mark Mentovai wrote:
> >
> > The macOS 13 SDK (and equivalent-version iOS and other Apple OS SDKs)
> > contain this definition in :
> >
> > 863 #define __null_terminated
> >
> > This collides with the use of __null_terminated in libstdc++'s
> > experimental fs_path.h.
> >
> > As libstdc++'s use of this token is entirely internal to fs_path.h, the
> > simplest workaround, renaming it, is most appropriate. Here, it's
> > renamed to __nul_terminated, referencing the NUL ('\0') value that is
> > used to terminate the strings in the context in which this tag structure
> > is used.
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/experimental/bits/fs_path.h: Rename __null_terminated
> > to __nul_terminated avoid colliding with a macro in Apple's SDK.
> >
> > Signed-off-by: Mark Mentovai
>
> Thanks for the patch. The change makes sense so I'll get it committed.
> Is this change needed on the release branches too?
>
> Just to be sure, could you please confirm that your Signed-off-by: tag
> is to certify you agree with the DCO at https://gcc.gnu.org/dco.html
> (and not just something you're doing because you've seen others doing
> it :-)
>
> Thanks again.
>
>
