-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature #129884
Conversation
rustbot has assigned @petrochenkov. Use |
f8424ee
to
191ef36
Compare
This comment has been minimized.
This comment has been minimized.
Some changes occurred in compiler/rustc_codegen_gcc |
This comment has been minimized.
This comment has been minimized.
df74d6b
to
a340e78
Compare
Some changes occurred in tests/ui/check-cfg cc @Urgau |
bbf47ab
to
319aafa
Compare
This comment was marked as outdated.
This comment was marked as outdated.
@@ -328,6 +355,7 @@ const X86_ALLOWED_FEATURES: &[(&str, Stability, ImpliedFeatures)] = &[ | |||
("sha512", Unstable(sym::sha512_sm_x86), &["avx2"]), | |||
("sm3", Unstable(sym::sha512_sm_x86), &["avx"]), | |||
("sm4", Unstable(sym::sha512_sm_x86), &["avx2"]), | |||
("soft-float", Forbidden, &[]), // changes float ABI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ARM targets also have a soft-float
target feature. Aarch64 does not, though -- so we can't just add this for all targets, unfortunately.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aarch64 has abi: "softfloat"
:
abi: "softfloat".into(), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That seems like it cannot be changed with -Ctarget-feature
, which is good news.
This comment was marked as resolved.
This comment was marked as resolved.
0ae9f0e
to
b67a656
Compare
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 |
b67a656
to
3e44287
Compare
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. |
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. |
This comment has been minimized.
This comment has been minimized.
In fact rustc already checks that the content of the target spec file matches for custom target specs ever since #98225. |
AFAICT, on x86(-64), |
3e44287
to
098469e
Compare
The problematic case is 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. :) |
…, r=workingjubilee mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature The context for this is rust-lang#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 and ARM feature `soft-float` is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in rust-lang#131799.) 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
…kingjubilee Rollup of 10 pull requests Successful merges: - rust-lang#129884 (mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature) - rust-lang#132153 (Stabilise `const_char_encode_utf16`.) - rust-lang#132473 ([core/fmt] Replace checked slice indexing by unchecked to support panic-free code) - rust-lang#132571 (add const_eval_select macro to reduce redundancy) - rust-lang#132587 (Revert "Avoid nested replacement ranges" from rust-lang#129346.) - rust-lang#132596 ([rustdoc] Fix `--show-coverage` when JSON output format is used) - rust-lang#132598 (Clippy: Move some attribute lints to be early pass (post expansion)) - rust-lang#132601 (Update books) - rust-lang#132606 (Improve example of `impl Pattern for &[char]`) - rust-lang#132609 (docs: fix grammar in doc comment at unix/process.rs) r? `@ghost` `@rustbot` modify labels: rollup
…r=workingjubilee mark some target features as 'forbidden' so they cannot be (un)set with -Ctarget-feature The context for this is rust-lang#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 and ARM feature `soft-float` is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in rust-lang#131799.) 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
💔 Test failed - checks-actions |
The musl job timed out? @bors retry |
@bors rollup=iffy |
☀️ Test successful - checks-actions |
Finished benchmarking commit (e8c698b): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is the most reliable metric that we have; it was used to determine the overall result at the top of this comment. However, even this metric can sometimes exhibit noise.
Max RSS (memory usage)Results (primary -0.9%, secondary -1.5%)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.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 780.065s -> 779.96s (-0.01%) |
…s, r=workingjubilee forbid toggling x87 and fpregs on hard-float targets Part of rust-lang#116344, follow-up to rust-lang#129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](rust-lang#130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes rust-lang#132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
…ingjubilee forbid toggling x87 and fpregs on hard-float targets Part of rust-lang/rust#116344, follow-up to rust-lang/rust#129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](rust-lang/rust#130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes rust-lang/rust#132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
…ingjubilee forbid toggling x87 and fpregs on hard-float targets Part of rust-lang/rust#116344, follow-up to rust-lang/rust#129884: The `x87` target feature on x86 and the `fpregs` target feature on ARM must not be disabled on a hardfloat target, as that would change the float ABI. However, *enabling* `fpregs` on ARM is [explicitly requested](rust-lang/rust#130988) as it seems to be useful. Therefore, we need to refine the distinction of "forbidden" target features and "allowed" target features: all (un)stable target features can determine on a per-target basis whether they should be allowed to be toggled or not. `fpregs` then checks whether the current target has the `soft-float` feature, and if yes, `fpregs` is permitted -- otherwise, it is not. (Same for `x87` on x86). Also fixes rust-lang/rust#132351. Since `fpregs` and `x87` can be enabled on some builds and disabled on others, it would make sense that one can query it via `cfg`. Therefore, I made them behave in `cfg` like any other unstable target feature. The first commit prepares the infrastructure, but does not change behavior. The second commit then wires up `fpregs` and `x87` with that new infrastructure. r? `@workingjubilee`
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 and ARM feature
soft-float
is on that list. We'll have to make some effort to collect more relevant features, and similar features from other targets, but that can happen after the basic infrastructure for this landed. (These features are being collected in #131799.)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