Closed fxcoudert closed 2 years ago
Compiling that backport to the 10 branch is currently hitting a snag. I get:
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1233:3: error: expected expression
AARCH64_INIT_MEMTAG_BUILTINS_DECL (IRG, irg, irg, fntype);
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1229:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1237:3: error: expected expression
AARCH64_INIT_MEMTAG_BUILTINS_DECL (GMI, gmi, gmi, fntype);
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1229:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1241:3: error: expected expression
AARCH64_INIT_MEMTAG_BUILTINS_DECL (SUBP, subp, subp, fntype);
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1229:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1245:3: error: expected expression
AARCH64_INIT_MEMTAG_BUILTINS_DECL (INC_TAG, inc_tag, addg, fntype);
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1229:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1248:3: error: expected expression
AARCH64_INIT_MEMTAG_BUILTINS_DECL (SET_TAG, set_tag, stg, fntype);
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1229:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1251:3: error: expected expression
AARCH64_INIT_MEMTAG_BUILTINS_DECL (GET_TAG, get_tag, ldg, fntype);
^
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1229:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
{T, CODE_FOR_##I};
^
150 warnings and 6 errors generated.
make[3]: *** [aarch64-builtins.o] Error 1
This is not actually code that you've touched, and it looks like the same code is in master, so I'm unsure what's going on.
The motivation is that Homebrew will prefer to ship a version that's as close as possible to a released version, instead of shipping a "random" point of the 11 development tree. Most of the code is actually pretty unchanged since 10 and 11, so I think it's doable. For most of your commits, if they didn't apply cleanly at least I could clearly figure out where the relevant code was in the 10 branch, and make it work. I kept notes at https://github.com/fxcoudert/gcc/blob/gcc-10-arm/00TODO
I’d like to clean the patch set up really it’s a very messy “experimental” set at present… … hopefully that’s feasible (i.e. a rev #2 10.x can be done?)
Some of the support patches [for macOS 11, in general] should be applied to open branches - I have another small one for dealing with the different rules for mapping darwin kernel version to macOS to be applied soon.
There's currently only one commit that I could not figure how to backport, because I can't locate the equivalent codepath in 10: it is 1cf917f If you have any suggestion on how to backport this, it would be welcome.
The patch to support .cfi_xxx is not on the 10.x branch (and might never be, it’s not strictly addressing a regression - although it might address a bug at some point).
So that change (1cf917f) is not needed for now.
Compiling that backport to the 10 branch is currently hitting a snag. I get:
../../gcc/gcc/config/aarch64/aarch64-builtins.c:1233:3: error: expected expression AARCH64_INIT_MEMTAG_BUILTINS_DECL (IRG, irg, irg, fntype); ^ <snip> 150 warnings and 6 errors generated. make[3]: *** [aarch64-builtins.o] Error 1
This is not actually code that you've touched, and it looks like the same code is in master, so I'm unsure what's going on.
Me neither from that ... do you have a cfarm account? (there are aarch64 linux boxes there - so that, at least, one can confirm things are OK on a non-Darwin box).
It seems it's a clang issue:
$ cat a.c
struct
{
int ftype;
int icode;
} aarch64_memtag_builtin_data[10];
static void
aarch64_init_memtag_builtins (void)
{
aarch64_memtag_builtin_data[0] = {12, 42};
}
$ g++-10 -std=gnu++98 -c a.c
a.c:5:3: warning: unnamed type with no linkage used to declare variable '<unnamed struct> aarch64_memtag_builtin_data [10]' with linkage
5 | } aarch64_memtag_builtin_data[10];
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
a.c: In function 'void aarch64_init_memtag_builtins()':
a.c:10:43: warning: extended initializer lists only available with '-std=c++11' or '-std=gnu++11'
10 | aarch64_memtag_builtin_data[0] = {12, 42};
| ^
a.c:10:43: warning: extended initializer lists only available with '-std=c++11' or '-std=gnu++11'
$ clang++ -std=gnu++98 -c a.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
a.c:10:36: error: expected expression
aarch64_memtag_builtin_data[0] = {12, 42};
^
1 error generated.
$ clang++ -std=gnu++11 -c a.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Wdeprecated]
I don't know why it doesn't trigger on your branch, though… the code is the same
I found it. In GCC master, the top-level configure.ac has:
# When bootstrapping with GCC, build stage 1 in C++11 mode to ensure that a
# C++11 compiler can still start the bootstrap. Otherwise, if building GCC,
# require C++11 (or higher).
if test "$enable_bootstrap:$GXX" = "yes:yes"; then
CXX="$CXX -std=c++11"
elif test "$have_compiler" = yes; then
AX_CXX_COMPILE_STDCXX(11)
if test "${build}" != "${host}"; then
AX_CXX_COMPILE_STDCXX(11, [], [], [_FOR_BUILD])
fi
fi
but on gcc 10, it has:
# When bootstrapping with GCC, build stage 1 in C++98 mode to ensure that a
# C++98 compiler can still start the bootstrap.
if test "$enable_bootstrap:$GXX" = "yes:yes"; then
CXX="$CXX -std=gnu++98"
fi
try your example with -std=c++11 (that's what master uses).
yeah .. you got it (but that doesn't explain why it's not failing for the branch on other platforms)
perhaps GCC warns (not errors) for that - and therefore, it never shows because stage2 and 3 get built with the default which for GCC10 is std=c++14
I tried using gnu++11
but this leads to:
../../gcc/gcc/config/darwin.c:1357:16: error: no viable conversion from 'poly_uint16' (aka 'poly_int<2, unsigned short>') to 'unsigned int'
unsigned int modesize = GET_MODE_BITSIZE (mode);
^ ~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/gcc/config/darwin.c:1752:28: error: invalid operands to binary expression ('poly_uint16' (aka 'poly_int<2, unsigned short>') and 'int')
if (GET_MODE_SIZE (mode) == 8
~~~~~~~~~~~~~~~~~~~~ ^ ~
../../gcc/gcc/wide-int.h:3289:19: note: candidate template ignored: substitution failure [with T1 = poly_int<2, unsigned short>, T2 = int]: implicit instantiation of undefined template
'wi::int_traits<poly_int<2, unsigned short> >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
../../gcc/gcc/config/darwin.c:1757:33: error: invalid operands to binary expression ('poly_uint16' (aka 'poly_int<2, unsigned short>') and 'int')
else if (GET_MODE_SIZE (mode) == 4
~~~~~~~~~~~~~~~~~~~~ ^ ~
../../gcc/gcc/wide-int.h:3289:19: note: candidate template ignored: substitution failure [with T1 = poly_int<2, unsigned short>, T2 = int]: implicit instantiation of undefined template
'wi::int_traits<poly_int<2, unsigned short> >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
../../gcc/gcc/config/darwin.c:1764:29: error: invalid operands to binary expression ('poly_uint16' (aka 'poly_int<2, unsigned short>') and 'int')
&& GET_MODE_SIZE (mode) == 16
~~~~~~~~~~~~~~~~~~~~ ^ ~~
../../gcc/gcc/wide-int.h:3289:19: note: candidate template ignored: substitution failure [with T1 = poly_int<2, unsigned short>, T2 = int]: implicit instantiation of undefined template
'wi::int_traits<poly_int<2, unsigned short> >'
BINARY_PREDICATE (operator ==, eq_p)
^
../../gcc/gcc/wide-int.h:3266:3: note: expanded from macro 'BINARY_PREDICATE'
OP (const T1 &x, const T2 &y) \
^
And -std=c++11
leads to the same issue.
I'm trying to patch aarch64-builtins.c
:
diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c
index cba596765..184e9095d 100644
--- a/gcc/config/aarch64/aarch64-builtins.c
+++ b/gcc/config/aarch64/aarch64-builtins.c
@@ -1225,8 +1225,9 @@ aarch64_init_memtag_builtins (void)
= aarch64_general_add_builtin ("__builtin_aarch64_memtag_"#N, \
T, AARCH64_MEMTAG_BUILTIN_##F); \
aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_##F - \
- AARCH64_MEMTAG_BUILTIN_START - 1] = \
- {T, CODE_FOR_##I};
+ AARCH64_MEMTAG_BUILTIN_START - 1].ftype = T; \
+ aarch64_memtag_builtin_data[AARCH64_MEMTAG_BUILTIN_##F - \
+ AARCH64_MEMTAG_BUILTIN_START - 1].icode = CODE_FOR_##I;
fntype = build_function_type_list (ptr_type_node, ptr_type_node,
uint64_type_node, NULL);
That works but I get the same error as the comment above. Still, progress.
I think this should be fixed properly on the branch - it's probably an oversight (was just discussing with Nathan - and his view is that stages 2 and 3 should have been built with explicit gnu++98 which would have Werror'd when it was master). So what would be good would be to find a way to repeat this for a non-arm64-darwin case and report a PR.
the first issue could be fixed thus: struct __ aarch64_memtagbuiltin { int ftype; int icode; } aarch64_memtag_builtin_data[10];
the second (using the initialiser) needs some thing more
I have aarch64-builtins.c
taken care of, now I need some help with darwin.c
. I've sent an email to the gcc list
see my reply - I think you need to back port : 7ddee9cd99b
With luck I will take some time to do some patch clean-up over the holidays, so should be able to help with the back porting maybe next week.
Backport of https://github.com/iains/gcc-darwin-arm64/commit/7ddee9cd99beb2c3603bf307d263c6fd9cc05e90 helps indeed, next issue:
g++ -std=gnu++98 -no-pie -g -DIN_GCC -fno-strict-aliasing -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -o xgcc gcc.o gcc-main.o ggc-none.o \
c/gccspec.o driver-aarch64.o darwin-driver.o libcommon-target.a \
libcommon.a ../libcpp/libcpp.a ./../intl/libintl.a -liconv ../libbacktrace/.libs/libbacktrace.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
clang: warning: argument unused during compilation: '-no-pie' [-Wunused-command-line-argument]
Undefined symbols for architecture arm64:
"aarch64_get_extension_string_for_isa_flags(unsigned long, unsigned long)", referenced from:
host_detect_local_cpu(int, char const**) in driver-aarch64.o
Yet it is defined:
$ nm libcommon-target.a | grep aarch64_get_extension_string_for_isa_flags
00000000000006f8 T __Z42aarch64_get_extension_string_for_isa_flagsyy
double-check gcc/config.gcc ? make sure that the right objects are included? (there have been some changes around option handling on master.. but I didn't need to touch any of that, so another possibility is an unintended hunk in the back ports)
It's a signature change, I think, long
vs long long
(I'm really bad at C++, which is why I didn't think of it immediately):
$ nm libcommon-target.a | grep aarch64_get_extension_string_for_isa_flags | c++filt
00000000000006f8 T aarch64_get_extension_string_for_isa_flags(unsigned long long, unsigned long long)
Logical fix:
diff --git a/gcc/config/aarch64/driver-aarch64.c b/gcc/config/aarch64/driver-aarch64.c
index 8840a2d94..d99834c99 100644
--- a/gcc/config/aarch64/driver-aarch64.c
+++ b/gcc/config/aarch64/driver-aarch64.c
@@ -27,8 +27,7 @@
#include "tm.h"
/* Defined in common/config/aarch64/aarch64-common.c. */
-std::string aarch64_get_extension_string_for_isa_flags (unsigned long,
- unsigned long);
+std::string aarch64_get_extension_string_for_isa_flags (uint64_t, uint64_t);
struct aarch64_arch_extension
{
I am not sure / don't think that we use the uint64_t style inside the compiler. perhaps __UINT64_TYPE__ or long long unsigned int (which will be the same type for 32 and 64b hosts, where unsigned long isn't)
heh __UINT64_TYPE__
or long long unsigned int
It seems happy with uint64_t
, and it is was is used in the function definition, so it might as well be in the prototype.
Now I have finished building gcc, but:
/dev/null:1: internal compiler error: in darwin_gt_pch_use_address, at config/host-darwin.c:51
I cannot get a backtrace because lldb says it's missing a GUI connection. Wonderful.
you need ... 590febb5f66 Darwin: Adjust the PCH area to allow for 16384byte page size.
hopefully, this isn't a poor use of your time (it seems you found a couple of real bugs en route).
@iains I knew given my limited skills this would be like playing hide-and-seek… I'm sorry to bother you so much, though.
I thought I had backported all your patches, though… don't know why this one escaped me
there might be more :/ ... I have tried to upstream as much as possible to make the final patch as small as viable
(it's no prob, I was intending to do a 10.2 set of back ports for x86_64-darwin20 anyway - and make an 'official' branch) .. you are doing some of the leg work :)
It's kinda ironic that we need to set the PCH area page size correctly, even tho we can't use the PCH... ... actually, now I have Darwin20 on X86_64, it seems the pagesize there is still 4096 .. I might eventually tweak that change to be conditional on arm64 or something - but it's OK as is for now.
Now does this ring a bell?
/var/folders/vc/9n6c_r253cddwcx2lgcqd1280000gp/T//ccpY8hhG.s:32:18: error: expected 'sxtx' 'uxtx' or 'lsl' with optional integer in range [0, 4]
sub x2, x2, x3, sxtw
^
make[3]: *** [_floattisf_s.o] Error 1
yes // a set of changes was needed... I originally made a set of patches (perhaps if you look on the earliest preserved arm64 branch[es]) .. then the Arm folks took it on an made the necessary changes "officially" .. so it's much hard for me to find the relevant patches -- except that I did comment on some of them onlist.
4062fbb96417ccdcbe290fe65d8fc0535ea8e79b 6d78d3c5b6364068da412ef1e6e5dcbac51da5c6
^^^ BUT better to find Alex's actual commits that fixed this and back port those.
there was some other assembler syntax change - but I think that's still a live patch?
A bunch of what I'm trying to do next is to 'un hack' the necessary changes - especially the ones needed for *darwin*
and commit those upstream. The next set are ones connected with configuration (default OS versions etc), ld64 (supported flags), dsymutil (fixing locating that properly) &c. it takes a bunch of time just to test these "across the patch".
Yeah it's hard for me to figure out what has been upstreamed to master but not backported to 10. I now get:
xgcc: warning: ‘11.0’ is not valid for ‘mmacosx-version-min’
object file (_udivmoddi4_s.o) was built for newer macOS version (11.0) than being linked (10.4)
ld: warning: could not create compact unwind for ___enable_execute_stack: registers 19 and 20 not saved contiguously in frame
ld: symbol dyld_stub_binding_helper not found, normally in crt1.o/dylib1.o/bundle1.o for architecture arm64
collect2: error: ld returned 1 exit status
and I'm sure you have an earlier patch for that, but I can't figure out which.
OK
556ab512591 Darwin: Darwin 20 is to be macOS 11 (Big Sur).
I haven't committed the patch yet that fixes the macOS version to the new rules for kernel version <=> macOS version [subject of an email recently to @jeremyhu]. This evening (it's a follow-on to the one above, we didn't know the minor version rules then).
I think I did patch to stuff a higher min version for the libgcc build to > 10.4
These patches (already on master) are on my 'back port queue' for 10.x - and indeed earlier so that the open branches will build for x86_64 on Darwin20, at least. (independent of the Arm64 effort)
Bootstrap is proceeding, but I get a ton of these warnings:
In file included from ./tm.h:26,
from ../../gcc/gcc/backend.h:28,
from ../../gcc/gcc/loop-iv.c:54:
../../gcc/gcc/config/darwin.h:662: warning: "ASM_DECLARE_FUNCTION_NAME" redefined
662 | #define ASM_DECLARE_FUNCTION_NAME(FILE, NAME, DECL) \
|
In file included from ./tm.h:25,
from ../../gcc/gcc/backend.h:28,
from ../../gcc/gcc/loop-iv.c:54:
../../gcc/gcc/config/aarch64/aarch64.h:615: note: this is the location of the previous definition
615 | #define ASM_DECLARE_FUNCTION_NAME(STR, NAME, DECL) \
|
In file included from ./tm.h:26,
from ../../gcc/gcc/backend.h:28,
from ../../gcc/gcc/loop-iv.c:54:
../../gcc/gcc/config/darwin.h:1072: warning: "DEF_MIN_OSX_VERSION" redefined
1072 | #define DEF_MIN_OSX_VERSION "10.5"
|
In file included from ../../gcc/gcc/backend.h:28,
from ../../gcc/gcc/loop-iv.c:54:
./tm.h:19: note: this is the location of the previous definition
19 | # define DEF_MIN_OSX_VERSION "11.0"
|
I'm thinking this is not fine, especially for DEF_MIN_OSX_VERSION
, since the smaller value overrides the larger one. What do you think?
yeah, looks like something is out of order or missing #undef ..
please could you cat gcc/tm.h
(in the build build dir) ?
$ cat gcc/tm.h
#ifndef GCC_TM_H
#define GCC_TM_H
#ifndef LIBC_GLIBC
# define LIBC_GLIBC 1
#endif
#ifndef LIBC_UCLIBC
# define LIBC_UCLIBC 2
#endif
#ifndef LIBC_BIONIC
# define LIBC_BIONIC 3
#endif
#ifndef LIBC_MUSL
# define LIBC_MUSL 4
#endif
#ifndef TARGET_DEFAULT_ASYNC_UNWIND_TABLES
# define TARGET_DEFAULT_ASYNC_UNWIND_TABLES 1
#endif
#ifndef DEF_MIN_OSX_VERSION
# define DEF_MIN_OSX_VERSION "11.0"
#endif
#ifdef IN_GCC
# include "options.h"
# include "insn-constants.h"
# include "config/aarch64/biarchlp64.h"
# include "config/aarch64/aarch64.h"
# include "config/darwin.h"
# include "config/darwin9.h"
# include "config/darwin10.h"
# include "config/darwin12.h"
# include "config/aarch64/darwin.h"
# include "config/aarch64/aarch64-errata.h"
# include "config/initfini-array.h"
#endif
#if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET
# include "insn-flags.h"
#endif
#if defined IN_GCC && !defined GENERATOR_FILE
# include "insn-modes.h"
#endif
# include "defaults.h"
#endif /* GCC_TM_H */
And gcc/gcc/config/darwin.h
does not check whether it's already defined.
then there's a missing patch/hunk .. because the (working) master list looks much the same:
#ifdef IN_GCC
# include "options.h"
# include "insn-constants.h"
# include "config/aarch64/biarchlp64.h"
# include "config/aarch64/aarch64.h"
# include "config/darwin.h"
# include "config/darwin9.h"
# include "config/darwin10.h"
# include "config/darwin12.h"
# include "config/aarch64/darwin.h"
# include "config/aarch64/aarch64-errata.h"
# include "config/initfini-array.h"
#endif
adding the obvious #undef to ASM_DECLARE_FUNCTION_NAME should be OK
conversely, the code for DEF_MIN_OSX_VERSION should be conditional on there being no prior def.
I'm sure I fixed this .. and, given that master builds on the DTK which is pushed from the current branch, I must have also committed the fixes :)
I haven't committed the patch yet that fixes the macOS version to the new rules for kernel version <=> macOS version [subject of an email recently to @jeremyhu]. This evening (it's a follow-on to the one above, we didn't know the minor version rules then).
now I have ... GCC master : 0e1d4b3bfe260667fb8e055ebff2b34d8a2ec253
So the results of the backport for Fortran are in (make check-gcc still running). Not great, because some of the Fortran front-end fixes were never backported.
=== gfortran Summary ===
# of expected passes 52668
# of unexpected failures 772
# of expected failures 230
# of unresolved testcases 6
# of unsupported tests 253
back porting takes effort - of course - but it might be nice to have a better release branch than that - perhaps worth discussing with Thomas et. al.?
My intention (time and $dayjob willing) is to have darwin-specific branches on gcc.gnu.org where there are critical patches needed on closed branches - or back ports that are not considered acceptable to the shared branches (e.g. things that Darwin needs, but are strictly not regression fixes).
These will [probably] live either in vendors/darwin or users/darwin and thus can be considered as 'official upstream' for the purposes of policy on use. (There's nothing unusual about this arrangment, the major vendors do the same).
.. in the short-term my github branches are placeholders for this.
I intend to backport the changes that can be safely made. There are 4 Fortran patches:
and 2 aarch64 patches that should be in this category:
did you have any luck locating the actual commits by Alex that fixed the assembler issues? (I think that it might be worth they to track them down, my memory was that the discussion on the patch review resulted in a more comprehensive fix - it might be that also could be considered relevant for backport).
I used those in your comment above: https://github.com/iains/gcc-darwin-arm64/issues/31#issuecomment-749039445 Right now I'm aiming to see what a quick backport gives, I'll try to upstream things where I can later.
fair enough - I rebased roughly weekly - so it should be possible to narrow the week down by seeing when those patches disappeared.
Fortran results, after the 4 backports above: really good! This is on par with the 11 branch.
=== gfortran Summary ===
# of expected passes 53390
# of unexpected failures 56
# of expected failures 230
# of unresolved testcases 6
# of unsupported tests 253
/Users/brew/gcc-10/ibin/gcc/gfortran version 10.2.1 20201220 (GCC)
For check-gcc
I get:
=== gcc Summary ===
# of expected passes 131616
# of unexpected failures 495
# of unexpected successes 7
# of expected failures 727
# of unresolved testcases 32
# of unsupported tests 3270
/Users/brew/gcc-10/ibin/gcc/xgcc version 10.2.1 20201220 (GCC)
@iains the test results above seem pretty much "in line" (broadly speaking) with master/11. Do you see anything there that would need to be investigated more? Or that looks suspicious?
without looking harder ;) .. it would be reasonable to expect 10.x and master to be similar. once i have the x86 back ports lined up, we can compare notes.
First testing of my backport is OK, but I am having an issue with MACOSX_DEPLOYMENT_TARGET=11
not begin accepted:
brew@28105 ~ % cat a.f90
program test
end
brew@28105 ~ % gfortran a.f90
brew@28105 ~ % MACOSX_DEPLOYMENT_TARGET=11 gfortran a.f90
gfortran: warning: couldn't understand version 11
ld: -pie requires targetting a newer minimum version
collect2: error: ld returned 1 exit status
Homebrew does set MACOSX_DEPLOYMENT_TARGET to the major macOS version in most cases, and with Big Sur that major version is 11. clang and other Apple build tools accept it.
Does 11.1 work?
I suspect the MACOSX_DEPLOYMENT_TARGET has never had to handle just the major version (is that even a valid deployment target ?)
(will look at making 10 == 10.0 and 11 == 11.0 .. but I don't think 11.0 was ever released?)
Hi @iains, I'm trying a backport of your patches to GCC 10 at https://github.com/fxcoudert/gcc/tree/gcc-10-arm
The motivation is that Homebrew will prefer to ship a version that's as close as possible to a released version, instead of shipping a "random" point of the 11 development tree. Most of the code is actually pretty unchanged since 10 and 11, so I think it's doable. For most of your commits, if they didn't apply cleanly at least I could clearly figure out where the relevant code was in the 10 branch, and make it work. I kept notes at https://github.com/fxcoudert/gcc/blob/gcc-10-arm/00TODO
There's currently only one commit that I could not figure how to backport, because I can't locate the equivalent codepath in 10: it is https://github.com/iains/gcc-darwin-arm64/commit/1cf917fa3baa8b40ae1e223a2b820f2c3222753d If you have any suggestion on how to backport this, it would be welcome.