aarch64-softfloat: forbid enabling the neon target feature

[RalfJung]

This fixes #134375 in a rather crude way, by making the example not build any more on aarch64-unknown-none-softfloat. That is a breaking change since the "neon" aarch64 target feature is stable, but this is justified as a soundness fix. Note that it's not "neon" which is problematic but "fp-armv8"; however, the two are tied together by rustc.

More work on the LLVM side will be needed before we can let people use neon without impacting the ABI of float values (and, in particular, the ABI used by automatically inserted calls to libm functions, e.g. for int-to-float casts, which rustc has no control over).

Nominating for @rust-lang/lang since it is a breaking change. As-is this PR doesn't have a warning cycle; the hope is that the aarch64-unknown-none-softfloat target is sufficiently niche that there's no huge fallout and we can easily revert if it causes trouble. A warning cycle could be added but would need some dedicated rather hacky check in the target_feature attribute handling logic.

[rustbot]

r? @Noratrieb

rustbot has assigned @Noratrieb.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[RalfJung]

Cc @Darksonn @Amanieu, please chime in if there are any aarch64 stakeholders that need #[target_feature(enable = "neon")] on aarch64-unknown-none-softfloat.

[Darksonn]

This change looks good to me. On the off chance that a kernel user comes up in the near future, they can use the "be careful" approach you mentioned in #134375 (comment).

[RalfJung]

Yeah, separately building some crates with aarch64-unknown-none-softfloat and some with aarch64-unknown-none and linking them together should work (but I have not tested this, you may need separate sysroots and then link them together as C-style object files). Once we have the target modifier system it should flag this as incompatible, but that can be unsafely overruled.

[tgross35]

Once we have the target modifier system it should flag this as incompatible, but that can be unsafely overruled.

Will that mean something like #[unsafe(target_feature(enable = "neon"))] can enable this back?

[RalfJung]

I don't think we should allow target features to do that (I was imagining target modifiers would introduce a new flag for overriding ABI-relevant target features, if there's any good use for that), and so far there was no proposal to allow overriding target modifiers on a per-function basis.

The text you quoted referred to -C flags, not attributes.

[Amanieu]

I'm happy with this as long as we acknowledge that this is a temporary workaround until LLVM starts handling ABI independently of target features.

[RalfJung]

Fully agreed, the ideal end state is that we can use the FPU while sticking to a softfloat ABI (what clang and GCC do for -mfloat-abi=softfp on ARM-32). How temporary this will be depends on how long it takes until someone puts in the required work on the LLVM side.

[apiraino]

Was this discussed by T-lang prior to be approved? I assume yes since I see the release notes label, correct?

cc @traviscross probably knows

[RalfJung]

We are waiting for t-lang approval, hence the "I-lang-nominated" and "S-waiting-on-team" labels.