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.

-Ctarget-feature=+neon still works, it just causes a warning (but one that we do hope to make a hard error eventually). Only #[target_feature="neon"] becomes a hard error with this PR.

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.

try-job: dist-various-1

[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.

[tmandry]

@rfcbot fcp merge

[rfcbot]

Team member @tmandry has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[tmandry]

I would want relnotes to include a workaround (unfortunately, sounds like it's moving code into another crate and doing some cross-target shenanigans that cargo may not support). Since this is hitting an LLVM limitation it sounds like there's not much else we can do. But if there is any significant breakage we should revisit this decision.

[RalfJung]

-Ctarget-feature=+neon still works, it just causes a warning (but one that we do hope to make a hard error eventually). Only #[target_feature="neon"] becomes a hard error with this PR.

[tmandry]

@rfcbot fcp cancel

[bors]

☔ The latest upstream changes (presumably #141379) made this pull request unmergeable. Please resolve the merge conflicts.

[RalfJung]

@bors try

[bors]

⌛ Trying commit 3c020e5 with merge 4055942...

[bors]

☀️ Try build successful - checks-actions
Build commit: 4055942 (4055942696f7b675e87ed2f111126f531b9fd1b5)

[RalfJung]

@bors r=Noratrieb rollup=iffy

[bors]

📌 Commit 3c020e5 has been approved by Noratrieb

It is now in the queue for this repository.

[matthiaskrgr]

@bors p=4

[bors]

⌛ Testing commit 3c020e5 with merge e7f4317...

[bors]

☀️ Test successful - checks-actions
Approved by: Noratrieb
Pushing e7f4317 to master...

[github-actions]

What is this?

This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.

Comparing 912981a (parent) -> e7f4317 (this PR)

Test differences

Show 282 test diffs

Stage 1

• [ui] tests/ui/target-feature/abi-incompatible-target-feature-attribute-fcw.rs: [missing] -> pass (J0)
• errors::verify_codegen_ssa_aarch64_softfloat_neon_142: [missing] -> pass (J1)

Stage 2

• [ui] tests/ui/target-feature/abi-incompatible-target-feature-attribute-fcw.rs: [missing] -> pass (J2)

Additionally, 279 doctest diffs were found. These are ignored, as they are noisy.

Job group index

• J0: x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3
• J1: aarch64-apple, aarch64-gnu, i686-gnu-2, i686-gnu-nopt-2, i686-msvc-2, x86_64-apple-1, x86_64-gnu, x86_64-gnu-llvm-19-3, x86_64-gnu-llvm-20-3, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-2, x86_64-msvc-2
• J2: aarch64-apple, aarch64-gnu, arm-android, armhf-gnu, dist-i586-gnu-i586-i686-musl, i686-gnu-1, i686-gnu-nopt-1, i686-msvc-1, test-various, x86_64-apple-2, x86_64-gnu, x86_64-gnu-llvm-19-1, x86_64-gnu-llvm-19-2, x86_64-gnu-llvm-20-1, x86_64-gnu-llvm-20-2, x86_64-gnu-nopt, x86_64-gnu-stable, x86_64-mingw-1, x86_64-msvc-1

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \ test-dashboard e7f4317ea0e891296163414c6f681ccec976abc3 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. dist-apple-various: 6436.2s -> 8665.5s (34.6%)
2. dist-aarch64-apple: 5422.2s -> 6316.2s (16.5%)
3. dist-x86_64-apple: 8690.3s -> 9534.0s (9.7%)
4. x86_64-apple-2: 7269.9s -> 6683.2s (-8.1%)
5. dist-loongarch64-linux: 6656.5s -> 6226.7s (-6.5%)
6. dist-various-2: 3494.3s -> 3270.6s (-6.4%)
7. x86_64-msvc-ext1: 7028.7s -> 7440.2s (5.9%)
8. x86_64-apple-1: 7181.0s -> 7578.5s (5.5%)
9. dist-x86_64-msvc: 6524.0s -> 6164.4s (-5.5%)
10. dist-ohos-armv7: 4235.6s -> 4465.6s (5.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (e7f4317): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results (primary -0.7%, secondary 2.6%)

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.6%	[2.6%, 2.6%]	1
Improvements ✅ (primary)	-0.7%	[-0.7%, -0.7%]	1
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-0.7%	[-0.7%, -0.7%]	1

Cycles

This benchmark run did not return any relevant results for this metric.

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 777.508s -> 778.581s (0.14%)
Artifact size: 365.50 MiB -> 365.44 MiB (-0.02%)