reject aarch64 target feature toggling that would change the float ABI #133417
Conversation
|
rustbot has assigned @compiler-errors. Use |
rustbot
added
S-waiting-on-review
|
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 Some changes occurred in cfg and check-cfg configuration cc @Urgau Some changes occurred in compiler/rustc_codegen_gcc These commits modify compiler targets. |
| && !target.has_neg_feature("fp-armv8") | ||
| && !target.has_neg_feature("neon") | ||
| { | ||
| // neon is enabled by default, and has not been disabled, so enabling it again |
There was a problem hiding this comment.
I don't know where LLVM sets neon by default, so this claim is based on hearsay.
RalfJung
force-pushed
the
aarch64-float-abi
branch
from
0fb4919 to
42db03b
Compare
There was a problem hiding this comment.
oh interesting, this is triggered in an existing test...
There was a problem hiding this comment.
So what happens here is that the flag is -Ctarget-feature=-neon,+sve2, and sve2 implies neon. So it makes little sense to say -neon here. I think it's fine to show a warning (and eventually hard error) for that.
The alternative would be to have a completely different approach for this entire "forbidden features" thing, where we look at the final state of all features, not at the individual enabled/disabled features. But that seems a lot more complicated and requires hooking deeper into the backend.
|
☔ The latest upstream changes (presumably #133568) made this pull request unmergeable. Please resolve the merge conflicts. |
…e can be invalid to toggle Also rename some things for extra clarity
…target feature is allowed
RalfJung
force-pushed
the
aarch64-float-abi
branch
from
42db03b to
6cd9e62
Compare
|
☔ The latest upstream changes (presumably #133770) made this pull request unmergeable. Please resolve the merge conflicts. |
Stacked on top of #133099. Only the last two commits are new.
The first new commit lays the groundwork for separately controlling whether a feature may be enabled or disabled. The second commit uses that to make it illegal to disable the
neonfeature (which is only possible via-Ctarget-feature, and so the new check just adds a warning). Enabling theneonfeature remains allowed on targets that don't disableneonorfp-armv8, which is all our built-in targets. This way, the entire PR is not a breaking change.Fixes #131058 for hardfloat targets (together with #133102 which fixed it for softfloat targets).