Bug 96168 - GCC support for Apple Silicon (Arm64) on macOS requested
Summary: GCC support for Apple Silicon (Arm64) on macOS requested
Status: SUSPENDED
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 11.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on:
Blocks:
 
Reported: 2020-07-11 16:32 UTC by Claudia Pellegrino
Modified: 2021-09-12 23:45 UTC (History)
13 users (show)

See Also:
Host:
Target: aarch64-darwin
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-07-11 00:00:00


Attachments
Minimal shell script to reproduce the failure (824 bytes, Text/plain)
2020-07-11 16:32 UTC, Claudia Pellegrino
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Claudia Pellegrino 2020-07-11 16:32:55 UTC
Created attachment 48864 [details]
Minimal shell script to reproduce the failure

Dear GCC team,


Thanks in advance for hearing me out even though I have near-zero experience in C/C++ programming.

I assume you have heard of Apple’s plans to switch to aarch64 hardware for Macs.
As a maintainer for the Homebrew package manager for macOS, I’m trying to figure out how to build the most important FOSS projects on the new Apple Silicon hardware.

IIRC, there have been successful third-party efforts to build older GCC versions (such as GCC 4) for aarch64/Darwin already, targeting iOS. I have learned that it’s completely unfeasible to forward-port those so I haven’t tried that yet. But it shows that it’s not entirely unrealistic to build GCC 10 for aarch64/Darwin so I gave it a try.


Required information according to https://gcc.gnu.org/bugs/:

Exact version of gcc:
- I’m trying to build (bootstrap) gcc 10.1.0 from the source tarball.
- I’m running macOS 11.0 beta 1 on Apple Silicon.
- I’m using clang from Xcode 12 Beta 2.
- I have GNU make 3.81 installed, which was built from source using `brew install make`.

System type:
- Hardware rented out from Apple
- Based on Apple Silicon, which currently is an A12z SoC based on the armv8.3 architecture.

Options when GCC was configured/built:
- See attached shell script.

Exact command line passed to the gcc program triggering the bug:
- Not applicable because I’m trying to build GCC.
- For the exact command lines passed to clang, configure and make, please see the attached shell script.

Collection of source files for reproducing the bug, preferably a minimal set:
- See attached shell script.

Expected behavior:
- `make` builds GCC 10.1.0 and exits successfully.

Actual behavior:
- See description below.

Using information from the `gccint.info` file from GCC’s source tree, I managed to patch a few things to the best of my knowledge. But now I’m stuck with `make` failing at `config/aarch64/aarch64-builtins.c` as follows (edited for clarity):

```
../../gcc/config/aarch64/aarch64-builtins.c:1225:3: error: expected expression
  AARCH64_INIT_MEMTAG_BUILTINS_DECL (IRG, irg, irg, fntype);
  ^
../../gcc/config/aarch64/aarch64-builtins.c:1221:5: note: expanded from macro 'AARCH64_INIT_MEMTAG_BUILTINS_DECL'
                                {T, CODE_FOR_##I};
                                ^

[…]

149 warnings and 6 errors generated.
make[3]: *** [aarch64-builtins.o] Error 1
make[2]: *** [all-stage1-gcc] Error 2
make[1]: *** [stage1-bubble] Error 2
make: *** [all] Error 2
```

After `make` fails, I can immediately reproduce the exact same error messages again by running:

```
cd gcc && clang++ -DIN_GCC -Wno-invalid-offsetof -Wno-ignored-attributes -Wno-deprecated -Wno-macro-redefined -Wno-array-bounds -I. -I../../gcc -I../../include -I../../gcc/../libcpp/include -o aarch64.o ../../gcc/config/aarch64/aarch64-builtins.c
```

I have attached a shell script showing my exact build steps. The shell script is self-contained in the sense that it also applies the exact patches I made. (The bug tracker seems to allow only a single attachment.)

The name of the AARCH64_INIT_MEMTAG_BUILTINS_DECL macro suggests that this is about memory tagging. My test hardware is an Apple A12Z SoC, which is based on armv8.3, and I know it definitely doesn’t support memory tagging, nor any other armv8.5 feature. I aim to build for vanilla armv8 so I want to ignore any armv8.3 or .5 features for now, such as memory tagging and pointer authentication.

How do I tell `make` to ignore those features? What other things can I try for `make` to get past `aarch64-builtins.c` and to help get GCC building?


Thank you very much for your time and help.

Regards and greetings from Darmstadt, Germany,  
Claudia
Comment 1 Claudia Pellegrino 2020-07-11 16:39:51 UTC
For those who want to run the shell script out of the box without any modifications, the following requirements apply:

- You’re on Apple Silicon hardware.

- You’re running macOS 11.0 Beta 1 or newer.

- The gcc 10.1.0 source tarball has been extracted into a `gcc-10.1.0` subdirectory of the current working directory.

- Homebrew is installed and works.

The Homebrew requirement is just for convenience; the attached shell script installs gcc’s dependencies for you, including GNU make.
For in-detail guidance how to install Homebrew, consult https://brew.sh and https://github.com/Homebrew/brew/issues/7857. Alternatively, install the dependencies on your own but be aware that patches are needed for Apple Silicon, which the Homebrew formulae already include.
Comment 2 Andrew Pinski 2020-07-11 16:40:01 UTC
The abi support for aarch64 Darwin has not been added by anyone yet so this is not going to work until someone does a full port.
Comment 3 Andrew Pinski 2020-07-11 16:42:29 UTC
Someone will need to take the llvm port and then port the full ABI to gcc. This is not just as simple of what you did.
Comment 4 Claudia Pellegrino 2020-07-11 16:50:40 UTC
Thanks Andrew for the feedback. I wasn’t sure whether or not that has been done already.

Even though I’m unable to do it on my own: if anyone wants to give it a try, I’m happy to help out with testing at all stages.
Comment 5 Eric Gallager 2020-07-11 20:19:43 UTC
I asked about this on the mailing lists here: https://gcc.gnu.org/pipermail/gcc/2020-June/232922.html
Iain Sandoe and Mike Stump had some hints about how to proceed; cc-ing them
Comment 6 Iain Sandoe 2020-07-11 20:56:06 UTC
(In reply to Eric Gallager from comment #5)
> I asked about this on the mailing lists here:
> https://gcc.gnu.org/pipermail/gcc/2020-June/232922.html
> Iain Sandoe and Mike Stump had some hints about how to proceed; cc-ing them

It requires more or less a complete port (the amount of work depending on how divergent the ABI and/or ISA is/are from the ones currently supported by GCC).  We haven't begun to poke at this seriously yet.

Using the assembler / linker from LLVM upstream or Xcode is presumably possible (in the same way that we can for X86 and PPC).

As Andrew says, it's a (IMO very) significant undertaking;  to get a port into GCC11 would require the work to be complete and accepted by ≈ Dec 2020.  Ideally, someone would work on it full-time for their day job to achieve that ;)

(of course, that won't stop us trying - but you should set expectations realistically - spare time work is unlikely to achieve GCC11)
Comment 7 Claudia Pellegrino 2020-07-11 21:40:51 UTC
Thanks Eric, and thank you Iain for the ballpark estimate.

Just to add a piece of data to get a better idea of the work involved, here’s a link to a document published by Apple. It specifies how their ABI differs from the standard ARM64 one: https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html

Note that the document says iPhone OS but after a few cursory checks, the ABI of macOS 11 on Apple Silicon seems entirely identical to the iOS one – which makes sense, given the SoCs are the same and their kernels and large parts of either OS are known to be built from the same source.

To give proper credit: I didn’t do those quick checks myself but macOS/iOS security researcher Saagar Jha did, who is cc’ed on this bug and knows a ton more about Apple’s OSes than I do.
Comment 8 Keno Fischer 2020-07-11 23:40:17 UTC
Is there a list of all the things that need doing? I don't know very much about how GCC is architected (but am familiar with LLVM,MachO,Aarch64 ISA, etc), but from my naive point of view, at least

- Add all the ARM64 MachO relocations
- Add special cases for the Aarch64 ABI differences on Apple platforms
- Implement parsing/(& printing?) for Apple's assembly dialect
- Add CPU models for the relevant chips

The good news is that I don't think there's currently any proprietary ISA extensions that we would have to worry about, so most of the code generation should just go through.

I unfortunately don't have very much time myself either, but might able able to pick up a small piece. Perhaps we can subdivide the work and prioritize what's on the "critical path". I think the biggest reason people are clamoring for GCC support at the moment is that the platform otherwise has no fortran compiler, which is blocking a lot of the scientific computing stack. I think identifying a minimal "fortran-complete" path would be helpful and encourage people to help out :).
Comment 9 Andrew Pinski 2020-07-12 00:48:01 UTC
(In reply to Keno Fischer from comment #8)
> Is there a list of all the things that need doing? I don't know very much
> about how GCC is architected (but am familiar with LLVM,MachO,Aarch64 ISA,
> etc), but from my naive point of view, at least
> 
> - Add all the ARM64 MachO relocations
GCC does not output macho files directly, so this part is just printing.

> - Add special cases for the Aarch64 ABI differences on Apple platforms
This one should be the majority of the work really.

> - Implement parsing/(& printing?) for Apple's assembly dialect
The printing part is part of GCC, GCC has support for alternative dialect that can be used here.

> - Add CPU models for the relevant chips
You don't need this to start out with really, since ARMv8.3-a is backwards compatiable with ARMv8-a.  You could default the arch to armv8.3-a if you want.
Comment 10 Thomas Koenig 2020-08-18 06:45:17 UTC
Since there is no other viable Fortran compiler on iOS, this
means that packages like R, numpy and anything else will not
work on the new hardware.

I guess the advice will just have to be: Do not buy any new-style
Macs if you plan to do any scientific work at all until this has
been resolved.
Comment 11 Iain Sandoe 2020-08-18 07:47:00 UTC
(In reply to Thomas Koenig from comment #10)
> Since there is no other viable Fortran compiler on iOS,

AFAIK, iOS has not been supported by GCC since Apple gcc-4.2.1 and
the Apple releases didn't have gfortran.

this applies to the shift of macOS to arm64.
(although, ironically, supporting arm64 GCC on macOS would bring
 support to iOS too).

> this means that packages like R, numpy and anything else will not
> work on the new hardware.
> 
> I guess the advice will just have to be: Do not buy any new-style
> Macs if you plan to do any scientific work at all until this has
> been resolved.

https://github.com/iains/gcc-darwin-arm64#readme

.. but a volunteer effort and vying for time with every other
bug / enhancement.
Comment 12 Jeffrey Walton 2021-04-26 18:19:56 UTC
This may be helpful if someone starts on a port of GCC to the M1: https://developer.apple.com/documentation/xcode/writing_arm64_code_for_apple_platforms

The GCC Compile Farm has an M1. I also have an M1 for testing. My M1 has Command Line Tools (CLT), but lacks Xcode. (I don't have an Apple account anymore). My M1 has Autotools but that's about it. My M1 gives some projects some problems when they assume Xcode is present.

If you want an account on my box for testing, then send your authorized_keys to noloader, gmail account. If you break my M1 it is no big deal. I'll just reinstall the OS.