Skip to content
New issue

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

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

Already on GitHub? Sign in 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in 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