mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature

[RalfJung]

The context for this is #116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs.

So this introduces a new concept of "forbidden" target features (on top of the existing "stable " and "unstable" categories), and makes it a hard error to (un)set such a target feature. For now, the x86 features soft-float and x87 are on that list. We'll have to make some effort to collect similar features from other targets, but that can happen after the basic infrastructure for this landed.

I've made this a warning for now to give people some time to speak up if this would break something.

MCP: rust-lang/compiler-team#780

[rustbot]

r? @petrochenkov

rustbot has assigned @petrochenkov.
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

[rustbot]

Some changes occurred in compiler/rustc_codegen_gcc

cc @antoyo, @GuillaumeGomez

[rustbot]

Some changes occurred in tests/ui/check-cfg

cc @Urgau

[RalfJung]

ARM targets also have a soft-float target feature. Aarch64 does not, though -- so we can't just add this for all targets, unfortunately.

[bjorn3]

Aarch64 has abi: "softfloat":

rust/compiler/rustc_target/src/spec/targets/aarch64_unknown_none_softfloat.rs

Line 15 in 9b82580

abi: "softfloat".into(),

[RalfJung]

That seems like it cannot be changed with -Ctarget-feature, which is good news.

[VorpalBlade]

How does this affect kernel / bare metal builds on x86 where you don't enable any floating point support whatsoever? I know the Linux kernel uses that. I'm not sure what the status for Redox, etc is.

[RalfJung]

How does this affect kernel / bare metal builds on x86 where you don't enable any floating point support whatsoever? I know the Linux kernel uses that. I'm not sure what the status for Redox, etc is.

We have a x86_64-unknown-none soft-float target for them. I sure hope they don't use some other target and -Ctarget-features=+soft-float.

[bjorn3]

We have a x86_64-unknown-none soft-float target for them. I sure hope they don't use some other target and -Ctarget-features=+soft-float.

The kernel currently has a script generating a target spec for x86: https://github.com/Rust-for-Linux/linux/blob/rust-next/scripts/generate_rust_target.rs Arm64, riscv and loongarch use builtin bare-metal targets though.

[RalfJung]

Yeah anyone using custom targets can still set these target features in the target spec. I assume it is generally understood that code using different custom target specs cannot be linked together, so the same concerns do not apply there.

[bjorn3]

I assume it is generally understood that code using different custom target specs cannot be linked together

In fact rustc already checks that the content of the target spec file matches for custom target specs ever since #98225.

[beetrees]

The one exception is that it may be the case that on a target with +soft-float, it is okay to enable x87 as floats will still be returned in regular registers... I haven't checked this, so I am not sure. I would say this seems sufficiently niche that it's okay to reject this for now, and if the need really comes up we'll have to add a special case.

AFAICT, on x86(-64), soft-float completely disables use of floating-point registers and always uses software floating point operations regardless of which other target features are enabled, meaning that it's safe to enable the x87 feature (and other floating-point features) but completely useless (e.g. if you enable the sse feature and try to use an xmm_reg input/output in inline ASM, LLVM will emit rustc-LLVM ERROR: Do not know how to soften this operator's operand!).

[RalfJung]

AFAICT, on x86(-64), soft-float completely disables use of floating-point registers and always uses software floating point operations regardless of which other target features are enabled, meaning that it's safe to enable the x87 feature (and other floating-point features) but completely useless (e.g. if you enable the sse feature and try to use an xmm_reg input/output in inline ASM, LLVM will emit rustc-LLVM ERROR: Do not know how to soften this operator's operand!).

The problematic case is -x87 on what is usually a hardfloat target -- that will change ABI. So we have to make x87 "forbidden".

We could make it "forbidden to disable but not forbidden to enable", but if you're saying that enabling it is useless anyway then I suggest we go with "forbidden" now. :)

[bors]

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

[RalfJung]

MCP in rust-lang/compiler-team#780 has passed. The PR now does the conservative thing of emitting a warning rather than a hard error, pointing to #116344.

@petrochenkov this is ready for review.

[RalfJung]

@rustbot ready

[RalfJung]

Turns out ARM fpregs is sometimes needed on ARM when -Ctarget-cpu enables too many things on a soft-float target, and one needs to cut things back down to not have the FPU. This is sound as the target is +soft-float so toggling fpregs does not change the ABI -- but toggling fpregs on an eabihf target is not sound!

So we'll need to find a way to allow fpregs on some targets but disallow it on others. But that can be done in a next step, this PR is now restricted to the soft-float target feature which we do not want to be set either way for any target.

[bors]

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

[RalfJung]

Since we haven't heard from the reviewer in a while
r? compiler