Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Regression in target cfg for aarch64-apple-darwin: supposed support for actually missing architecture features #95064

Closed
pthariensflame opened this issue Mar 18, 2022 · 1 comment · Fixed by #91608
Labels
C-bug Category: This is a bug. O-AArch64 Armv8-A or later processors in AArch64 mode

Comments

@pthariensflame
Copy link
Contributor

I tried this shell invocation:

rustc +nightly --target=aarch64-apple-darwin --print cfg

I expected to see this happen: rustc reports the target cfgs that one would expect from "generic" aarch64-apple-darwin, notably not including SVE or anything depending on it.

Instead, this happened:

debug_assertions
panic="unwind"
target_abi=""
target_arch="aarch64"
target_endian="little"
target_env=""
target_family="unix"
target_feature="aes"
target_feature="crc"
target_feature="dit"
target_feature="dotprod"
target_feature="dpb"
target_feature="dpb2"
target_feature="f32mm"
target_feature="f64mm"
target_feature="fcma"
target_feature="fhm"
target_feature="flagm"
target_feature="fp"
target_feature="fp16"
target_feature="frintts"
target_feature="jsconv"
target_feature="llvm14-builtins-abi"
target_feature="lor"
target_feature="lse"
target_feature="neon"
target_feature="paca"
target_feature="pacg"
target_feature="pan"
target_feature="pmuv3"
target_feature="ras"
target_feature="rcpc"
target_feature="rcpc2"
target_feature="rdm"
target_feature="sb"
target_feature="sha2"
target_feature="sha3"
target_feature="ssbs"
target_feature="sve"
target_feature="sve2"
target_feature="sve2-aes"
target_feature="sve2-bitperm"
target_feature="sve2-sha3"
target_feature="sve2-sm4"
target_feature="v8.1a"
target_feature="v8.2a"
target_feature="v8.3a"
target_feature="v8.4a"
target_feature="vh"
target_has_atomic="128"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="128"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="64"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store="128"
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="64"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_os="macos"
target_pointer_width="64"
target_thread_local
target_vendor="apple"
unix

Meta

rustc +nightly --version --verbose:

rustc 1.61.0-nightly (58f11791a 2022-03-17)
binary: rustc
commit-hash: 58f11791af4f97572e7afd83f11cffe04bbbd12f
commit-date: 2022-03-17
host: x86_64-apple-darwin
release: 1.61.0-nightly
LLVM version: 14.0.0

This is a regression from previous versions of rustc, which (almost) accurately reflected the capabilities of Apple's M1 with respect to what rustc can make use of; rustc +nightly-2022-01-30 gives me:

debug_assertions
panic="unwind"
target_abi=""
target_arch="aarch64"
target_endian="little"
target_env=""
target_family="unix"
target_feature="aes"
target_feature="crc"
target_feature="dit"
target_feature="dotprod"
target_feature="dpb"
target_feature="dpb2"
target_feature="fcma"
target_feature="fhm"
target_feature="flagm"
target_feature="fp"
target_feature="fp16"
target_feature="frintts"
target_feature="jsconv"
target_feature="lor"
target_feature="lse"
target_feature="neon"
target_feature="pan"
target_feature="pauth"
target_feature="pmuv3"
target_feature="ras"
target_feature="rcpc"
target_feature="rcpc2"
target_feature="rdm"
target_feature="sb"
target_feature="sha2"
target_feature="sha3"
target_feature="ssbs"
target_feature="v8.1a"
target_feature="v8.2a"
target_feature="v8.3a"
target_feature="v8.4a"
target_feature="vh"
target_has_atomic="128"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_has_atomic_equal_alignment="128"
target_has_atomic_equal_alignment="16"
target_has_atomic_equal_alignment="32"
target_has_atomic_equal_alignment="64"
target_has_atomic_equal_alignment="8"
target_has_atomic_equal_alignment="ptr"
target_has_atomic_load_store="128"
target_has_atomic_load_store="16"
target_has_atomic_load_store="32"
target_has_atomic_load_store="64"
target_has_atomic_load_store="8"
target_has_atomic_load_store="ptr"
target_os="macos"
target_pointer_width="64"
target_thread_local
target_vendor="apple"
unix

(This is just one version I knew didn't have the problem; the regression may be more recent than that; the only thing wrong with this output is pmuv3, which Apple M1 doesn't implement because its PMU interface is very nonstandard.)

@pthariensflame pthariensflame added the C-bug Category: This is a bug. label Mar 18, 2022
@workingjubilee workingjubilee added the O-AArch64 Armv8-A or later processors in AArch64 mode label Mar 23, 2022
@workingjubilee
Copy link
Member

This is almost certainly the issue tracked in #95122

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
C-bug Category: This is a bug. O-AArch64 Armv8-A or later processors in AArch64 mode
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants