[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

(resent with correct address for Iain)

This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume that if the 
OS version is >= 20, the compiler should see --mmacosx-version-min={major - 9}.{minor -1}.0, 
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same 
arguments).

However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
 -triple x86_64-apple-macosx12.0.0
and the linker sees
 -platform_version macos 12.0.0 
the result of which is that linking an object file built with clang and one built with gcc gives e.g.

 ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0)

I propose the following patch, which works fine for me (darwin 21.3.0).

gcc/ChangeLog:
	
	2022-06-02  Simon Wright  <simon@pushface.org>
	
	PR target/104871
	* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS version is
          20 (macOS 11) or greater, report the minor version and the patch level as 0
          to match Apple clang’s behaviour.


[-- Attachment #2: pr104871.diff --]
[-- Type: application/octet-stream, Size: 1323 bytes --]

diff --git a/gcc/config/darwin-driver.cc b/gcc/config/darwin-driver.cc
index 30e0e64f280..c47599e3fcb 100644
--- a/gcc/config/darwin-driver.cc
+++ b/gcc/config/darwin-driver.cc
@@ -160,19 +160,13 @@ darwin_find_version_from_kernel (void)
     goto parse_failed;
 
   /* Darwin20 sees a transition to macOS 11.  In this, it seems that the
-     mapping to macOS minor version is now shifted to the kernel minor
-     version - 1 (at least for the initial releases).  */
+     mapping to macOS minor version and patch level is now always 0, 0
+     (at least for macOS 11 and 12).  */
   if (major_vers >= 20)
     {
-      int minor_vers = *version_p++ - '0';
-      if (ISDIGIT (*version_p))
-	minor_vers = minor_vers * 10 + (*version_p++ - '0');
-      if (*version_p++ != '.')
-	goto parse_failed;
-      if (minor_vers > 0)
-	minor_vers -= 1; /* Kernel 20.3 => macOS 11.2.  */
-      /* It's not yet clear whether patch level will be considered.  */
-      asprintf (&new_flag, "%d.%02d.00", major_vers - 9, minor_vers);
+      /* Apple clang doesn't include the minor version or the patch level
+         in the object file, nor does it pass it to ld  */
+      asprintf (&new_flag, "%d.00.00", major_vers - 9);
     }
   else if (major_vers - 4 <= 4)
     /* On 10.4 and earlier, the old linker is used which does not

Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[Iain Sandoe]

Hi Simon,

thanks for the patch.

> On 11 Jun 2022, at 10:17, Simon Wright <simon@pushface.org> wrote:
> 
> (resent with correct address for Iain)
> 
> This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume that if the 
> OS version is >= 20, the compiler should see --mmacosx-version-min={major - 9}.{minor -1}.0, 
> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same 
> arguments).
> 
> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
> -triple x86_64-apple-macosx12.0.0
> and the linker sees
> -platform_version macos 12.0.0 
> the result of which is that linking an object file built with clang and one built with gcc gives e.g.
> 
> ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0)
> 
> I propose the following patch, which works fine for me (darwin 21.3.0).

this LGTM - just need to sort out a couple of nits and an admin point.

FWIW; the following are honoured in preserving the minor version (so we still have scope for
mismatches if some objects are built this way and others picking up the kernel version) ..

clang -target x86_64-apple-macosx11.3 …
clang -mmacosx-version-min=11.3 …
MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one version
of xcodem to pass 12.3 to the linker.. hmmm).

I guess you do not have commit access? 
if you do not have an FSF assignment for copyright, are you OK to sign this off using the DCO?

 https://gcc.gnu.org/dco.html

for furture reference, please check that patches conform to GCC coding style (this one has some
whitespace glitches)

thanks,
Iain


> gcc/ChangeLog:
> 	
> 	2022-06-02  Simon Wright  <simon@pushface.org>
> 	
> 	PR target/104871
> 	* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS version is
>          20 (macOS 11) or greater, report the minor version and the patch level as 0
>          to match Apple clang’s behaviour.
> 
> <pr104871.diff>

Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[Simon Wright]

On 11 Jun 2022, at 11:37, Iain Sandoe <iain@sandoe.co.uk> wrote:
> 
> Hi Simon,
> 
> thanks for the patch.
> 
>> On 11 Jun 2022, at 10:17, Simon Wright <simon@pushface.org> wrote:
>> 
>> (resent with correct address for Iain)
>> 
>> This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume that if the 
>> OS version is >= 20, the compiler should see --mmacosx-version-min={major - 9}.{minor -1}.0, 
>> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same 
>> arguments).
>> 
>> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
>> -triple x86_64-apple-macosx12.0.0
>> and the linker sees
>> -platform_version macos 12.0.0 
>> the result of which is that linking an object file built with clang and one built with gcc gives e.g.
>> 
>> ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0)
>> 
>> I propose the following patch, which works fine for me (darwin 21.3.0).
> 
> this LGTM - just need to sort out a couple of nits and an admin point.
> 
> FWIW; the following are honoured in preserving the minor version (so we still have scope for
> mismatches if some objects are built this way and others picking up the kernel version) ..
> 
> clang -target x86_64-apple-macosx11.3 …
> clang -mmacosx-version-min=11.3 …
> MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one version
> of xcodem to pass 12.3 to the linker.. hmmm).

Something on the lines of "the native compiler clang treats 21.3.0 as 12.0.0 (unless overridden by e.g. 
MACOSX_DEPLOYMENT_TARGET=11.3 )"?

I did see in the otool -l report on a gcc 12.1.0 executable generated as above (Darwin 21.5.0)

      cmd LC_BUILD_VERSION
  cmdsize 32
 platform 1
    minos 11.3
      sdk 10.17

— don’t know where the 10.17 comes from, still there even without MACOSX_DEPLOYMENT_TARGET.
The SDK was Xcode 13.4.1. I also have CLT 13.4.0.0.1.1651278267. clang tells ld 
"-platform_version macos 11.3.0 12.3", gcc just says "-macosx_version_min 11.3".

> I guess you do not have commit access? 
> if you do not have an FSF assignment for copyright, are you OK to sign this off using the DCO?
> 
> https://gcc.gnu.org/dco.html <https://gcc.gnu.org/dco.html>

No commit access, but FSF assignment RT:1016382. Do I need to say this in the patch email somewhere?

> for furture reference, please check that patches conform to GCC coding style (this one has some
> whitespace glitches)

I don’t see the whitespace glitches? (I have missed a period after ld in the second comment)

> 
> thanks,
> Iain
> 
> 
>> gcc/ChangeLog:
>> 	
>> 	2022-06-02 Simon Wright <simon@pushface.org <mailto:simon@pushface.org>>
>> 	
>> 	PR target/104871
>> 	* config/darwin-driver.cc <http://darwin-driver.cc/> (darwin_find_version_from_kernel): If the OS version is
>> 20 (macOS 11) or greater, report the minor version and the patch level as 0
>> to match Apple clang’s behaviour.
>> 
>> <pr104871.diff>

Re: [PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[Iain Sandoe]

Hi Simon,

> On 11 Jun 2022, at 20:23, Simon Wright <simon@pushface.org> wrote:
> 
> On 11 Jun 2022, at 11:37, Iain Sandoe <iain@sandoe.co.uk> wrote:
>> 
>> Hi Simon,
>> 
>> thanks for the patch.
>> 
>>> On 11 Jun 2022, at 10:17, Simon Wright <simon@pushface.org> wrote:
>>> 
>>> (resent with correct address for Iain)
>>> 
>>> This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume that if the 
>>> OS version is >= 20, the compiler should see --mmacosx-version-min={major - 9}.{minor -1}.0, 
>>> e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same 
>>> arguments).
>>> 
>>> However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
>>> -triple x86_64-apple-macosx12.0.0
>>> and the linker sees
>>> -platform_version macos 12.0.0 
>>> the result of which is that linking an object file built with clang and one built with gcc gives e.g.
>>> 
>>> ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0)
>>> 
>>> I propose the following patch, which works fine for me (darwin 21.3.0).
>> 
>> this LGTM - just need to sort out a couple of nits and an admin point.
>> 
>> FWIW; the following are honoured in preserving the minor version (so we still have scope for
>> mismatches if some objects are built this way and others picking up the kernel version) ..
>> 
>> clang -target x86_64-apple-macosx11.3 …
>> clang -mmacosx-version-min=11.3 …
>> MACOSX_DEPLOYMENT_TARGET=11.3 clang … (although this seems on at least one version
>> of xcodem to pass 12.3 to the linker.. hmmm).
> 
> Something on the lines of "the native compiler clang treats 21.3.0 as 12.0.0 (unless overridden by e.g. 
> MACOSX_DEPLOYMENT_TARGET=11.3 )"?
> 
> I did see in the otool -l report on a gcc 12.1.0 executable generated as above (Darwin 21.5.0)
> 
>       cmd LC_BUILD_VERSION
>   cmdsize 32
>  platform 1
>     minos 11.3
>       sdk 10.17
> 
> — don’t know where the 10.17 comes from,

That’s the version of the SDK in use (it’s embedded in the plist of the SDK except in the very early ones).
The full -platform_version command has a space for the SDK, perhaps ld64 looks it up these days if not
supplied on the command line.  Odd that it’s named 10.17 instead of 11.x

(the latest sources for ld64 are quite old now, so can’t check what newer versions of the linker are doing).

> still there even without MACOSX_DEPLOYMENT_TARGET.
> The SDK was Xcode 13.4.1. I also have CLT 13.4.0.0.1.1651278267. clang tells ld 
> "-platform_version macos 11.3.0 12.3", gcc just says "-macosx_version_min 11.3".

GCC does not implement  the -platform_version command yet (we have a configure scan for it but
not needed to use it so far) - not sure if we really want to get into parsing plist files to find the SDK version
(or get tied to using more tools out of our control).

>> I guess you do not have commit access? 
>> if you do not have an FSF assignment for copyright, are you OK to sign this off using the DCO?
>> 
>> https://gcc.gnu.org/dco.html
> 
> No commit access, but FSF assignment RT:1016382. Do I need to say this in the patch email somewhere?

no, that’s fine - we just need one (assignment) or the other (DCO).

>> for furture reference, please check that patches conform to GCC coding style (this one has some
>> whitespace glitches)
> 
> I don’t see the whitespace glitches? (I have missed a period after ld in the second comment)

sets of 8 leading spaces should be tabs.
the source tree has some checking tools for commits (in contrib/ ), which can be useful.
It’s also quite handy to have the entire commit with the commit message in one’s local repo and then
just do “git format-patch -1 xxxxxxxxxxx” to get the patch for posting (but, of course, everyone has
their own favourite git workflow).

OK, thanks, I think I’ve got everything needed to get this applied, there’s no need to re-issue, I’ll tweak
the commit message and the whitespace.

Iain

> 
>> 
>> thanks,
>> Iain
>> 
>> 
>>> gcc/ChangeLog:
>>> 	
>>> 	2022-06-02 Simon Wright <simon@pushface.org>
>>> 	
>>> 	PR target/104871
>>> 	* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS version is
>>> 20 (macOS 11) or greater, report the minor version and the patch level as 0
>>> to match Apple clang’s behaviour.
>>> 
>>> <pr104871.diff>

[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 1111 bytes --]

(resent with commit message format update)

This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume that if the 
OS version is >= 20, the compiler should see --mmacosx-version-min={major - 9}.{minor -1}.0, 
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same 
arguments).

However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
  -triple x86_64-apple-macosx12.0.0
and the linker sees
  -platform_version macos 12.0.0 
the result of which is that linking an object file built with clang and one built with gcc gives e.g.

  ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0)

I propose the following patch, which works fine for me (darwin 21.3.0).

gcc/ChangeLog:
	
	2022-06-02  Simon Wright  <simon@pushface.org>
	
	PR target/104871
	* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS version is
           20 (macOS 11) or greater, report the minor version and the patch level as 0
           to match Apple clang’s behaviour.


[-- Attachment #2: pr104871.diff --]
[-- Type: application/octet-stream, Size: 1323 bytes --]

diff --git a/gcc/config/darwin-driver.cc b/gcc/config/darwin-driver.cc
index 30e0e64f280..c47599e3fcb 100644
--- a/gcc/config/darwin-driver.cc
+++ b/gcc/config/darwin-driver.cc
@@ -160,19 +160,13 @@ darwin_find_version_from_kernel (void)
     goto parse_failed;
 
   /* Darwin20 sees a transition to macOS 11.  In this, it seems that the
-     mapping to macOS minor version is now shifted to the kernel minor
-     version - 1 (at least for the initial releases).  */
+     mapping to macOS minor version and patch level is now always 0, 0
+     (at least for macOS 11 and 12).  */
   if (major_vers >= 20)
     {
-      int minor_vers = *version_p++ - '0';
-      if (ISDIGIT (*version_p))
-	minor_vers = minor_vers * 10 + (*version_p++ - '0');
-      if (*version_p++ != '.')
-	goto parse_failed;
-      if (minor_vers > 0)
-	minor_vers -= 1; /* Kernel 20.3 => macOS 11.2.  */
-      /* It's not yet clear whether patch level will be considered.  */
-      asprintf (&new_flag, "%d.%02d.00", major_vers - 9, minor_vers);
+      /* Apple clang doesn't include the minor version or the patch level
+         in the object file, nor does it pass it to ld  */
+      asprintf (&new_flag, "%d.00.00", major_vers - 9);
     }
   else if (major_vers - 4 <= 4)
     /* On 10.4 and earlier, the old linker is used which does not

[PATCH] Fix PR target/104871 (macosx-version-min wrong for macOS >= Big Sur (darwin20))

[Simon Wright]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

This is the same sort of problem as in PR80204: at present, GCC 11 & 12 assume that if the 
OS version is >= 20, the compiler should see --mmacosx-version-min={major - 9}.{minor -1}.0, 
e.g. for OS version 21.3.0 that would be 12.2.0 (the linker sees -macosx-version-min, same 
arguments).

However, the native compiler clang treats 21.3.0 as 12.0.0: the compiler sees
   -triple x86_64-apple-macosx12.0.0
and the linker sees
   -platform_version macos 12.0.0 
the result of which is that linking an object file built with clang and one built with gcc gives e.g.

   ld: warning: object file (null.o) was built for newer macOS version (12.2) than being linked (12.0)

I propose the following patch, which works fine for me (darwin 21.3.0).

gcc/ChangeLog:
	
	2022-06-02 Simon Wright <simon@pushface.org>
	
	PR target/104871
	* config/darwin-driver.cc (darwin_find_version_from_kernel): if the OS version is
            20 (macOS 11) or greater, report the minor version and the patch level as 0
            to match Apple clang’s behaviour.


[-- Attachment #2: pr104871.diff --]
[-- Type: application/octet-stream, Size: 1323 bytes --]

diff --git a/gcc/config/darwin-driver.cc b/gcc/config/darwin-driver.cc
index 30e0e64f280..c47599e3fcb 100644
--- a/gcc/config/darwin-driver.cc
+++ b/gcc/config/darwin-driver.cc
@@ -160,19 +160,13 @@ darwin_find_version_from_kernel (void)
     goto parse_failed;
 
   /* Darwin20 sees a transition to macOS 11.  In this, it seems that the
-     mapping to macOS minor version is now shifted to the kernel minor
-     version - 1 (at least for the initial releases).  */
+     mapping to macOS minor version and patch level is now always 0, 0
+     (at least for macOS 11 and 12).  */
   if (major_vers >= 20)
     {
-      int minor_vers = *version_p++ - '0';
-      if (ISDIGIT (*version_p))
-	minor_vers = minor_vers * 10 + (*version_p++ - '0');
-      if (*version_p++ != '.')
-	goto parse_failed;
-      if (minor_vers > 0)
-	minor_vers -= 1; /* Kernel 20.3 => macOS 11.2.  */
-      /* It's not yet clear whether patch level will be considered.  */
-      asprintf (&new_flag, "%d.%02d.00", major_vers - 9, minor_vers);
+      /* Apple clang doesn't include the minor version or the patch level
+         in the object file, nor does it pass it to ld  */
+      asprintf (&new_flag, "%d.00.00", major_vers - 9);
     }
   else if (major_vers - 4 <= 4)
     /* On 10.4 and earlier, the old linker is used which does not