Conversation
hughcars
force-pushed
the
fix-march-native-arm
branch
2 times, most recently
from
7aebc4d to
9de00a7
Compare
hughcars
force-pushed
the
fix-march-native-arm
branch
4 times, most recently
from
a7d2a66 to
c8b366f
Compare
|
Your branch is missing 160 commits - we made some changes to the makefile in those commits so could you update your branch to be in line with our main please? |
| MARCHFLAG.clang := $(MARCHFLAG.gcc) | ||
| # GCC: use -march=native only on x86 (where -mcpu doesn't exist); use -mcpu=native elsewhere | ||
| MARCHFLAG.gcc := $(if $(filter x86_64 i%86,$(UNAME_M)),-march=native,-mcpu=native) | ||
| MARCHFLAG.clang := -march=native |
There was a problem hiding this comment.
| MARCHFLAG.clang := -march=native | |
| MARCHFLAG.clang := $(MARCHFLAG.gcc) |
I believe clang works the same way as gcc in this regard so I think this line should be reverted.
$ clang -E --target=aarch64 -march=apple-m1 -x c /dev/null
clang: error: unsupported argument 'apple-m1' to option '-march='In contrast, this is successful:
$ clang -E --target=aarch64 -mcpu=apple-m1 -x c /dev/nullThere was a problem hiding this comment.
I'd wanted to try and figure out the details here before engaging either of you (the PR description isn't even right any more), but thank you for taking an early look. I think you're right, and had undone it, the UNAME_M approach here is I think better than the -c vs -E I originally tried (but broke the powerpc CI).
The "gcc" on macOS is a symlink to Apple Clang, so the existing matrix was testing Apple Clang twice instead of testing distinct compilers. Fix by testing three explicit compilers on macOS: - clang: Apple Clang (system) - gcc-15: real GCC from Homebrew - llvm: LLVM 18 from Homebrew Print compiler version to make the distinction visible in CI output.
On ARM, -march=native resolves to CPU names (e.g., apple-m1) which are invalid for -march; must use -mcpu=native instead. Use uname -m to detect architecture and select the appropriate flag. Clang has the same limitation, so MARCHFLAG.clang follows MARCHFLAG.gcc.
hughcars
force-pushed
the
fix-march-native-arm
branch
from
c8b366f to
7247fd9
Compare
Sorry about that, I made a mistake in starting the branch from my main which hadn't updated in a while, rather than origin main, pulled those in and pushed now. |
|
I think the change now is as minimal as i can. There's some risk of cross compiling I think, in that uname is about the current machine, but given I've only reliably been able to make this break in spack, this seems ok. The later cc flag checking is possibly redundant now, but I opted to leave it for defense in depth, and because I've no idea what other edge case build it might be protecting in addition to this change. The CI job might want to be renamed to gcc rather than gcc-15, happy to change that if you'd like. |
That would be very helpful if you don't mind. Thanks for the good fix |
Map compiler display names to actual binaries in a step instead of using matrix include/exclude, so job names stay as gcc/clang. Adds a separate apple-clang job on macOS to test the system compiler.
3 participants
When building with spack on ARM (Apple Silicon), GCC's
-march=nativefails:This occurs because spack's compiler wrapper causes
-march=nativeto resolve to CPU names likeapple-m1, but GCC's-marchdoesn't accept CPU names on ARM—only-mcpudoes. Fix by detecting architecture viauname -mand using-mcpu=nativeon non-x86 platforms.Reproducer with spack on macOS ARM:
Also changes the macos CI to use gcc/clang from homebrew, as
gccclangare aliases for apple-clang.