Incorrect target feature shown during `asm!` verification (aarch64)

[lylythechosenone]

Code

asm!("ldp d0, d1, [x0, 0x100]");

Current output

error: instruction requires: fp-armv8
   --> /Users/lysan/.cargo/git/checkouts/unwinding-943b7a48f658f090/5718f01/src/unwinder/arch/aarch64.rs:101:13
    |
101 |             ldp d0, d1, [x0, 0x100]
    |             ^
    |
note: instantiated into assembly here
   --> <inline asm>:2:13
    |
2   |             ldp d0, d1, [x0, 0x100]
    |             ^

Desired output

error: instruction requires: neon
   --> /Users/lysan/.cargo/git/checkouts/unwinding-943b7a48f658f090/5718f01/src/unwinder/arch/aarch64.rs:101:13
    |
101 |             ldp d0, d1, [x0, 0x100]
    |             ^
    |
note: instantiated into assembly here
   --> <inline asm>:2:13
    |
2   |             ldp d0, d1, [x0, 0x100]
    |             ^

Rationale and extra context

This error only appears on aarch64-unknown-none-softfloat (all other aarch64s have neon).

fp-armv8 is not an aarch64 feature, it's an arm feature. neon is the equivalent aarch64 feature afaict.

Other cases

No response

Rust Version

rustc 1.80.0-nightly (804421dff 2024-06-07)
binary: rustc
commit-hash: 804421dff5542c9c7da5c60257b5dbc849719505
commit-date: 2024-06-07
host: aarch64-apple-darwin
release: 1.80.0-nightly
LLVM version: 18.1.7

Anything else?

No response

[bjorn3]

LLVM accepts fp-armv8 on AArch64: https://github.com/llvm/llvm-project/blob/bf7c505847aa58af23f14ee986ee4bb7acf22e62/llvm/lib/Target/AArch64/AArch64Features.td#L105-L107 neon implies fp-armv8 and vice versa: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/AArch64Features.td#L112

And in fact if I use -Ctarget-feature=+fp-armv8 it compiles fine: https://rust.godbolt.org/z/9en9M7Tab

Also note that this error message come directly from LLVM. The only thing rustc has control over is the exact format the error message is rendered in.

[lylythechosenone]

it may work, but it's certainly not correct. For example, rust-analyzer sees fp-armv8 as nonexistent and always marks it as disabled.

As for the second part, I can see how that would be a problem. I guess parsing llvm errors is not something we really want to do.