[Bug bootstrap/96168] New: Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[Bug bootstrap/96168] New: Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[gcczilla at cpellegrino dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

            Bug ID: 96168
           Summary: Cannot bootstrap with Xcode 12 Beta on aarch64, macOS
                    11.0/Darwin, Apple Silicon
           Product: gcc
           Version: 10.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: gcczilla at cpellegrino dot de
  Target Milestone: ---

Created attachment 48864
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48864&action=edit
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

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[gcczilla at cpellegrino dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #1 from Claudia Pellegrino <gcczilla at cpellegrino dot de> ---
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.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |SUSPENDED
   Last reconfirmed|                            |2020-07-11

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[gcczilla at cpellegrino dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #4 from Claudia Pellegrino <gcczilla at cpellegrino dot de> ---
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.

[Bug bootstrap/96168] Cannot bootstrap with Xcode 12 Beta on aarch64, macOS 11.0/Darwin, Apple Silicon

[egallager at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Eric Gallager <egallager at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |egallager at gcc dot gnu.org,
                   |                            |iains at gcc dot gnu.org,
                   |                            |mikestump at comcast dot net

--- Comment #5 from Eric Gallager <egallager at gcc dot gnu.org> ---
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

[Bug bootstrap/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|10.1.0                      |11.0
           Severity|normal                      |enhancement
            Summary|Cannot bootstrap with Xcode |GCC support for Apple
                   |12 Beta on aarch64, macOS   |Silicon (Arm64) on macOS
                   |11.0/Darwin, Apple Silicon  |requested

--- Comment #6 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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)

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[gcczilla at cpellegrino dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #7 from Claudia Pellegrino <gcczilla at cpellegrino dot de> ---
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.

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[keno at juliacomputing dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Keno Fischer <keno at juliacomputing dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |keno at juliacomputing dot com

--- Comment #8 from Keno Fischer <keno at juliacomputing dot com> ---
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 :).

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(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.

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
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.

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> ---
(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.

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[noloader at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Jeffrey Walton <noloader at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |noloader at gmail dot com

--- Comment #12 from Jeffrey Walton <noloader at gmail dot com> ---
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.

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[timturnerc at yahoo dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

Tim Turner <timturnerc at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |timturnerc at yahoo dot com

--- Comment #13 from Tim Turner <timturnerc at yahoo dot com> ---
amd64-linux-siginfo.c: Adjust include order to avoid gnulib error 
    http://www.compilatori.com/
    On Fedora rawhide, after updating to glibc-2.33, I'm seeing the
    following build failure:
    http://www.acpirateradio.co.uk/
      CXX    nat/amd64-linux-siginfo.o
    In file included from /usr/include/bits/sigstksz.h:24,
http://www.logoarts.co.uk/  
                     from /usr/include/signal.h:315,
                     from ../gnulib/import/signal.h:52,
http://www.slipstone.co.uk/  
                     from /ironwood1/sourceware-git/rawhide-gnulib
http://www.mconstantine.co.uk
/bld/../../worktree-gnulib/gdbserver/../gdb/nat/amd64-linux-siginfo.c:20:
http://embermanchester.uk/  
    ../gnulib/import/unistd.h:663:3: error: #error "Please include config.h
first."
      663 |  #error "Please include config.h first." http://connstr.net/  
          |   ^~~~~

    glibc-2.33 has changed signal.h to now include
http://www.go-mk-websites.co.uk/  <bits/sigstksz.h> which,
    in turn, includes <unistd.h>. http://joerg.li/  For a gdb build, this
causes the gnulib
    version of unistd.h to be pulled in first.  The build failure shown
https://www.mktrade.fi/
    above happens because gnulib's config.h has not been included before
    the include of <signal.h>. http://www.jopspeech.com/ 

    The fix is simple - we just rearrange the order of the header file
    includes to make sure that gdbsupport/ http://fishingnewsletters.co.uk/ 
commondefs.h is included before
    attempting to include signal.h.  Note that gdbsupport/commondefs.h
    includes <gnulib/config.h>. http://www.wearelondonmade.com/ 

    Build and regression tested on Fedora 33.  On Fedora rawhide, GDB
    builds again. https://waytowhatsnext.com/ 

    gdb/ChangeLog:
glibc-2.33 has changed signal.h to now include <bits/sigstksz.h> which,
    in turn, includes <unistd.h>. http://www.iu-bloomington.com/  For a gdb
build, this causes the gnulib
    version of unistd.h to be http://the-hunters.org/  pulled in first.  The
build failure shown
    above happens because gnulib's https://komiya-dental.com/ config.h has not
been included before
    the include of <signal.h>. http://www-look-4.com/ 

    The fix is simple - we just rearrange the order of the header file
https://www.webb-dev.co.uk/ 
    includes to make sure that gdbsupport/commondefs.h is included before
    attempting to include signal.h.  Note that gdbsupport/commondefs.h
    includes <gnulib/config.h>.

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> ---
please see the Work In Progress here:

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

this is a functional branch (although with known issues, since it is a
prototype)