[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 --- Comment #14 from Iain Sandoe --- 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)
[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Tim Turner changed: What|Removed |Added CC||timturnerc at yahoo dot com --- Comment #13 from Tim Turner --- 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/ CXXnat/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/ which, in turn, includes . 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 . 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 . 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 which, in turn, includes . 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 . 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 .
[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Jeffrey Walton changed: What|Removed |Added CC||noloader at gmail dot com --- Comment #12 from Jeffrey Walton --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 --- Comment #11 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #10 from Thomas Koenig --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 --- Comment #9 from Andrew Pinski --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 Keno Fischer changed: What|Removed |Added CC||keno at juliacomputing dot com --- Comment #8 from Keno Fischer --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168 --- Comment #7 from Claudia Pellegrino --- 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.
