Summary: | sys-devel/gcc - Generates invalid -march option when ARMv8 sha3 extensions present | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Leonid Kopylov <leonchik1976> |
Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | chewi, jstein |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | ARM64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
Leonid Kopylov
2022-12-17 18:21:01 UTC
Created attachment 843223 [details]
build.log
Your CFLAGS are broken. See man gcc. sha3 Enable the sha512 and sha3 crypto extension. This also enables Advanced SIMD instructions. Use of this option with architectures prior to Armv8.2-A is not supported. In other words, you would need to put -march=armv8.2-a. Seriously though, stop trying to be smarter than the compiler and just pick the CPU you actually have, like -mcpu=cortex-a55. Please also try without exotic CFLAGS before filing another bug report. (In reply to James Le Cuirot from comment #2) > Your CFLAGS are broken. See man gcc. > > sha3 > Enable the sha512 and sha3 crypto extension. This also enables > Advanced SIMD instructions. Use of this option with architectures prior to > Armv8.2-A is not supported. > > In other words, you would need to put -march=armv8.2-a. Seriously though, > stop trying to be smarter than the compiler and just pick the CPU you > actually have, like -mcpu=cortex-a55. Please also try without exotic CFLAGS > before filing another bug report. it failed with -march=native, so i expanded it according to: # gcc -march=native -E -v - </dev/null 2>&1 | grep cc1 /usr/libexec/gcc/aarch64-unknown-linux-gnu/12/cc1 -E -quiet -v - -mlittle-endian -mabi=lp64 -march=armv8-a+crypto+crc+lse+rcpc+rdma+dotprod+sha3+fp16fml+sb+ssbs+flagm+pauth -dumpbase - so what should i put in CFLAGS? Sorry. Please mention that in future so I don't jump to the wrong conclusion. This sounds like a bug in GCC. It blew up the same way for me with the explicit flags but -march=native works here. I don't have sha3 in /proc/cpuinfo though. Please post yours and let us know what board and CPU you actually have. I'll pass this over to the toolchain folks. (In reply to James Le Cuirot from comment #4) > Sorry. Please mention that in future so I don't jump to the wrong conclusion. > > This sounds like a bug in GCC. It blew up the same way for me with the > explicit flags but -march=native works here. I don't have sha3 in > /proc/cpuinfo though. Please post yours and let us know what board and CPU > you actually have. I'll pass this over to the toolchain folks. i have Apple Mac Studio - M1 Max (Gentoo installed inside Parallels Desktop VM) # cat /proc/cpuinfo processor : 0 BogoMIPS : 48.00 Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm jscvt fcma lrcpc dcpop sha3 asimddp sha512 asimdfhm dit uscat ilrcpc flagm ssbs sb paca pacg dcpodp flagm2 frint CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0x000 CPU revision : 0 Hmm, that complicates things. The last few fields being 0 there is probably related. The kernel is telling GCC it is the most basic ARMv8 CPU, except that it has all those extensions, which doesn't make sense. I cannot find a good example of what cpuinfo looks like on M1 bare metal. If it looked the same then it would be a kernel bug, although that seems unlikely. What seems more likely is that Parallels exposes bogus CPU info to the VM. I can see reports of Docker reporting similarly bogus information on M1 Macs. We cannot fix Parallels, so my suggestion would be to just not use -march=native. I'll let the toolchain folks decide though. (In reply to James Le Cuirot from comment #6) > Hmm, that complicates things. The last few fields being 0 there is probably > related. The kernel is telling GCC it is the most basic ARMv8 CPU, except > that it has all those extensions, which doesn't make sense. I cannot find a > good example of what cpuinfo looks like on M1 bare metal. If it looked the > same then it would be a kernel bug, although that seems unlikely. What seems > more likely is that Parallels exposes bogus CPU info to the VM. I can see > reports of Docker reporting similarly bogus information on M1 Macs. We > cannot fix Parallels, so my suggestion would be to just not use > -march=native. I'll let the toolchain folks decide though. i don't know if this can help, but using command from https://github.com/docker/for-mac/issues/6512 on macOS directly: => sysctl -a hw.optional hw.optional.arm.FEAT_FlagM: 1 hw.optional.arm.FEAT_FlagM2: 1 hw.optional.arm.FEAT_FHM: 1 hw.optional.arm.FEAT_DotProd: 1 hw.optional.arm.FEAT_SHA3: 1 hw.optional.arm.FEAT_RDM: 1 hw.optional.arm.FEAT_LSE: 1 hw.optional.arm.FEAT_SHA256: 1 hw.optional.arm.FEAT_SHA512: 1 hw.optional.arm.FEAT_SHA1: 1 hw.optional.arm.FEAT_AES: 1 hw.optional.arm.FEAT_PMULL: 1 hw.optional.arm.FEAT_SPECRES: 0 hw.optional.arm.FEAT_SB: 1 hw.optional.arm.FEAT_FRINTTS: 1 hw.optional.arm.FEAT_LRCPC: 1 hw.optional.arm.FEAT_LRCPC2: 1 hw.optional.arm.FEAT_FCMA: 1 hw.optional.arm.FEAT_JSCVT: 1 hw.optional.arm.FEAT_PAuth: 1 hw.optional.arm.FEAT_PAuth2: 0 hw.optional.arm.FEAT_FPAC: 0 hw.optional.arm.FEAT_DPB: 1 hw.optional.arm.FEAT_DPB2: 1 hw.optional.arm.FEAT_BF16: 0 hw.optional.arm.FEAT_I8MM: 0 hw.optional.arm.FEAT_ECV: 1 hw.optional.arm.FEAT_LSE2: 1 hw.optional.arm.FEAT_CSV2: 1 hw.optional.arm.FEAT_CSV3: 1 hw.optional.arm.FEAT_DIT: 1 hw.optional.arm.FEAT_FP16: 1 hw.optional.arm.FEAT_SSBS: 1 hw.optional.arm.FEAT_BTI: 0 hw.optional.arm.FP_SyncExceptions: 1 hw.optional.floatingpoint: 1 hw.optional.neon: 1 hw.optional.neon_hpfp: 1 hw.optional.neon_fp16: 1 hw.optional.armv8_1_atomics: 1 hw.optional.armv8_2_fhm: 1 hw.optional.armv8_2_sha512: 1 hw.optional.armv8_2_sha3: 1 hw.optional.armv8_3_compnum: 1 hw.optional.watchpoint: 4 hw.optional.breakpoint: 6 hw.optional.armv8_crc32: 1 hw.optional.armv8_gpi: 1 hw.optional.AdvSIMD: 1 hw.optional.AdvSIMD_HPFPCvt: 1 hw.optional.ucnormal_mem: 1 hw.optional.arm64: 1 |