add target feature ABI checks for SPARC by RalfJung · Pull Request #160562 · rust-lang/rust

RalfJung · 2026-08-05T12:38:54Z

Fixes #157083
MCP: rust-lang/compiler-team#1028

Cc @psumbera @kulikjak @workingjubilee @taiki-e @jonathanpallant I hope this makes sense :)

rustbot · 2026-08-05T12:38:57Z

These commits modify compiler targets.
(See the Target Tier Policy.)

rustbot · 2026-08-05T12:39:00Z

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

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: compiler
compiler expanded to 75 candidates
Random selection from 20 candidates

RalfJung · 2026-08-05T13:19:07Z

Ah, the sparc-unknown-linux-gnu target enables v8plus... that's a bit surprising given that I was told that the ABI isn't actually implemented in LLVM yet?
This is also a tier 3 target without a listed target maintainer, so I feel inclined to just remove the target feature from the target spec.

RalfJung · 2026-08-05T13:50:14Z

        VecDefault = "vec-default",
        VecExtAbi = "vec-extabi",
        X32 = "x32",
+        V8Plus = "v8plus",


Do we need any kind of process for a new cfg value here?

View changes since the review

I filed an MCP: rust-lang/compiler-team#1028

fee1-dead · 2026-08-09T18:51:19Z

@rustbot reroll

chenyukang · 2026-08-10T01:25:06Z

@rustbot reroll

hanna-kruppe · 2026-08-11T17:08:07Z

I don't really know anything about SPARC nor have I touched the compiler machinery for these checks yet. Maybe one of the people pinged earlier wants to take this? If not, I guess that's my chance to learn some more funny cursed trivia, but it'll take a while.

rustbot · 2026-08-17T09:30:36Z

These commits modify compiler targets.
(See the Target Tier Policy.)

rustbot · 2026-08-17T09:30:38Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

jonathanpallant · 2026-08-27T09:38:26Z

AFAIK this only applies to sparc-unknown-linux-gnu right? There is no target maintainer, nor platform docs page. So I think you can do whatever you like.

RalfJung · 2026-08-27T09:45:31Z

Oh, right.

RalfJung · 2026-08-27T19:30:04Z

We're going with "v8plus": #t-compiler/major changes > Expose `target_abi = "v8plus"` on sparc-… compiler-team#1028 @ 💬.

This PR is ready then :)

RalfJung · 2026-08-27T19:30:22Z

r? @tgross35

rustbot · 2026-08-27T19:30:28Z

tgross35 is currently at their maximum review capacity.
They may take a while to respond.

tgross35 · 2026-08-27T19:38:11Z

+                match self.rustc_abi {
+                    None => FeatureConstraints {
+                        required: &[],
+                        incompatible: &["soft-float", "v8plus"],
+                    },
+                    Some(RustcAbi::SparcV8Plus) => {
+                        FeatureConstraints { required: &["v8plus"], incompatible: &["soft-float"] }
+                    }
+                    _ => unreachable!(),
+                }
+            }
+            Arch::Sparc64 => {
+                // We currently don't have a soft-float target for SPARC64.
+                // v8plus is for 32bit SPARC only.
+                FeatureConstraints { required: &[], incompatible: &["soft-float", "v8plus"] }


Does the incompatible list make these target modifiers and prevent linking? I'm not sure whether that is something we should be testing.

View changes since the review

This system predates target modifiers so it is currently unrelated (though I am trying to marry them in #160593).

What this does is emit a warning whenever these target features are enabled via -Ctarget-feature or even implicitly via -Ctarget-cpu (with a note that this warning will become a hard error eventually). It also causes a hard error when they are enabled via #[target_feature].

tgross35

In that case, LGTM!

@bors r+

View changes since this review

rust-bors · 2026-08-27T21:12:32Z

📌 Commit e7cadc3 has been approved by tgross35

It is now in the queue for this repository.

@psumbera

add target feature ABI checks for SPARC Fixes rust-lang#157083 MCP: rust-lang/compiler-team#1028 Cc @psumbera @kulikjak @workingjubilee @taiki-e @jonathanpallant I hope this makes sense :)

@psumbera

add target feature ABI checks for SPARC Fixes rust-lang#157083 MCP: rust-lang/compiler-team#1028 Cc @psumbera @kulikjak @workingjubilee @taiki-e @jonathanpallant I hope this makes sense :)

…uwer Rollup of 21 pull requests Successful merges: - #158609 (Update sccache to 0.16.0) - #150075 (Implement clamp_to) - #159103 (fix(reborrow): recursive implementation) - #160562 (add target feature ABI checks for SPARC) - #160848 (std: avoid aliasing violations when wrapping opaque C types) - #161421 (Include startup crt objects on WASI for more outputs) - #161805 (Prefer ambiguous candidates when deduplicating traits in scope, so `ambiguous_glob_imported_traits` doesn't depend on import order) - #161862 (Put data segment in specified section with link_section on wasm) - #161866 (delegation: add tests fixating behavior of delegating to default trait implementations) - #161456 (reduce perf impact of scalar size checks) - #161528 (Add regression test to ensure optimal compilation) - #161666 (Print vendor instructions in `x vendor`) - #161730 (Improve type mismatch annotation for lets with block-wrapped initializers) - #161828 (Never type after-stabilization cleanup) - #161859 (Do not optimize MIR for comptime ConstFns) - #161860 (atomicptr.rs test: remove unused import) - #161870 (bind to [::1] instead of 127.0.0.1 in documentation examples for v6 UDP methods) - #161876 (rustdoc: Correctly handle when a macro generates multiple items in `--generate-macro-expansion`) - #161889 (Add link to ownership section in ptr::read docs) - #161890 (rustdoc: some clarifying comments) - #161891 (Mark `extern_item_impls` feature as incomplete) Failed merges: - #161702 (Use `drop_guard` in some places in {core,alloc,std})

…uwer Rollup of 21 pull requests Successful merges: - #150075 (Implement clamp_to) - #159103 (fix(reborrow): recursive implementation) - #160562 (add target feature ABI checks for SPARC) - #160848 (std: avoid aliasing violations when wrapping opaque C types) - #161421 (Include startup crt objects on WASI for more outputs) - #161805 (Prefer ambiguous candidates when deduplicating traits in scope, so `ambiguous_glob_imported_traits` doesn't depend on import order) - #161862 (Put data segment in specified section with link_section on wasm) - #161866 (delegation: add tests fixating behavior of delegating to default trait implementations) - #157218 (Track items behind `cfg_select` in the same way we do for `cfg`) - #161456 (reduce perf impact of scalar size checks) - #161528 (Add regression test to ensure optimal compilation) - #161666 (Print vendor instructions in `x vendor`) - #161730 (Improve type mismatch annotation for lets with block-wrapped initializers) - #161828 (Never type after-stabilization cleanup) - #161859 (Do not optimize MIR for comptime ConstFns) - #161860 (atomicptr.rs test: remove unused import) - #161870 (bind to [::1] instead of 127.0.0.1 in documentation examples for v6 UDP methods) - #161876 (rustdoc: Correctly handle when a macro generates multiple items in `--generate-macro-expansion`) - #161889 (Add link to ownership section in ptr::read docs) - #161890 (rustdoc: some clarifying comments) - #161891 (Mark `extern_item_impls` feature as incomplete) Failed merges: - #161702 (Use `drop_guard` in some places in {core,alloc,std})

@psumbera

Rollup merge of #160562 - RalfJung:sparc, r=tgross35 add target feature ABI checks for SPARC Fixes #157083 MCP: rust-lang/compiler-team#1028 Cc @psumbera @kulikjak @workingjubilee @taiki-e @jonathanpallant I hope this makes sense :)

…nathanBrouwer Rollup of 21 pull requests Successful merges: - rust-lang#150075 (Implement clamp_to) - rust-lang#159103 (fix(reborrow): recursive implementation) - rust-lang#160562 (add target feature ABI checks for SPARC) - rust-lang#160848 (std: avoid aliasing violations when wrapping opaque C types) - rust-lang#161421 (Include startup crt objects on WASI for more outputs) - rust-lang#161805 (Prefer ambiguous candidates when deduplicating traits in scope, so `ambiguous_glob_imported_traits` doesn't depend on import order) - rust-lang#161862 (Put data segment in specified section with link_section on wasm) - rust-lang#161866 (delegation: add tests fixating behavior of delegating to default trait implementations) - rust-lang#157218 (Track items behind `cfg_select` in the same way we do for `cfg`) - rust-lang#161456 (reduce perf impact of scalar size checks) - rust-lang#161528 (Add regression test to ensure optimal compilation) - rust-lang#161666 (Print vendor instructions in `x vendor`) - rust-lang#161730 (Improve type mismatch annotation for lets with block-wrapped initializers) - rust-lang#161828 (Never type after-stabilization cleanup) - rust-lang#161859 (Do not optimize MIR for comptime ConstFns) - rust-lang#161860 (atomicptr.rs test: remove unused import) - rust-lang#161870 (bind to [::1] instead of 127.0.0.1 in documentation examples for v6 UDP methods) - rust-lang#161876 (rustdoc: Correctly handle when a macro generates multiple items in `--generate-macro-expansion`) - rust-lang#161889 (Add link to ownership section in ptr::read docs) - rust-lang#161890 (rustdoc: some clarifying comments) - rust-lang#161891 (Mark `extern_item_impls` feature as incomplete) Failed merges: - rust-lang#161702 (Use `drop_guard` in some places in {core,alloc,std})

…uwer Rollup of 21 pull requests Successful merges: - rust-lang/rust#150075 (Implement clamp_to) - rust-lang/rust#159103 (fix(reborrow): recursive implementation) - rust-lang/rust#160562 (add target feature ABI checks for SPARC) - rust-lang/rust#160848 (std: avoid aliasing violations when wrapping opaque C types) - rust-lang/rust#161421 (Include startup crt objects on WASI for more outputs) - rust-lang/rust#161805 (Prefer ambiguous candidates when deduplicating traits in scope, so `ambiguous_glob_imported_traits` doesn't depend on import order) - rust-lang/rust#161862 (Put data segment in specified section with link_section on wasm) - rust-lang/rust#161866 (delegation: add tests fixating behavior of delegating to default trait implementations) - rust-lang/rust#157218 (Track items behind `cfg_select` in the same way we do for `cfg`) - rust-lang/rust#161456 (reduce perf impact of scalar size checks) - rust-lang/rust#161528 (Add regression test to ensure optimal compilation) - rust-lang/rust#161666 (Print vendor instructions in `x vendor`) - rust-lang/rust#161730 (Improve type mismatch annotation for lets with block-wrapped initializers) - rust-lang/rust#161828 (Never type after-stabilization cleanup) - rust-lang/rust#161859 (Do not optimize MIR for comptime ConstFns) - rust-lang/rust#161860 (atomicptr.rs test: remove unused import) - rust-lang/rust#161870 (bind to [::1] instead of 127.0.0.1 in documentation examples for v6 UDP methods) - rust-lang/rust#161876 (rustdoc: Correctly handle when a macro generates multiple items in `--generate-macro-expansion`) - rust-lang/rust#161889 (Add link to ownership section in ptr::read docs) - rust-lang/rust#161890 (rustdoc: some clarifying comments) - rust-lang/rust#161891 (Mark `extern_item_impls` feature as incomplete) Failed merges: - rust-lang/rust#161702 (Use `drop_guard` in some places in {core,alloc,std})

@Darksonn

…res, r=davidtwco turn ABI-controlling target features into a target modifier This makes it so that we can mark "internal" target features (which we track as target features in the compiler but do not expose as such to the user) as target modifiers, to be *really* sure that they are set consistently across all targets. For instance, if there was a value for `-Ctarget-cpu` that affected ABI-relevant target features, we'd catch mismatches in the value of that target feature. For now, this just complements the ABI check logic in `abi_required_features`, but I think long-term it might even be able to fully replace that logic. This would, for example, let us check consistency of the SPARC ABI (rust-lang#160562) without introducing a new variant for `RustcAbi`. OTOH having the ABI represented explicitly is often useful elsewhere in the compiler (e.g. for inline asm) so we may also want to keep both `abi_required_features` and this new concept of "target features that must be consistent across all crates". We could also eventually turn the target modifier into a safety net: if `abi_required_features` violations are a hard error and `-Ctarget-feature` is locked down to reject non-Rust target features, it should be impossible to ever violate the new target modifier check. Cc @Darksonn @workingjubilee

@Darksonn

…res, r=davidtwco turn ABI-controlling target features into a target modifier This makes it so that we can mark "internal" target features (which we track as target features in the compiler but do not expose as such to the user) as target modifiers, to be *really* sure that they are set consistently across all targets. For instance, if there was a value for `-Ctarget-cpu` that affected ABI-relevant target features, we'd catch mismatches in the value of that target feature. For now, this just complements the ABI check logic in `abi_required_features`, but I think long-term it might even be able to fully replace that logic. This would, for example, let us check consistency of the SPARC ABI (rust-lang#160562) without introducing a new variant for `RustcAbi`. OTOH having the ABI represented explicitly is often useful elsewhere in the compiler (e.g. for inline asm) so we may also want to keep both `abi_required_features` and this new concept of "target features that must be consistent across all crates". We could also eventually turn the target modifier into a safety net: if `abi_required_features` violations are a hard error and `-Ctarget-feature` is locked down to reject non-Rust target features, it should be impossible to ever violate the new target modifier check. Cc @Darksonn @workingjubilee

@Darksonn

…res, r=davidtwco turn ABI-controlling target features into a target modifier This makes it so that we can mark "internal" target features (which we track as target features in the compiler but do not expose as such to the user) as target modifiers, to be *really* sure that they are set consistently across all targets. For instance, if there was a value for `-Ctarget-cpu` that affected ABI-relevant target features, we'd catch mismatches in the value of that target feature. For now, this just complements the ABI check logic in `abi_required_features`, but I think long-term it might even be able to fully replace that logic. This would, for example, let us check consistency of the SPARC ABI (rust-lang#160562) without introducing a new variant for `RustcAbi`. OTOH having the ABI represented explicitly is often useful elsewhere in the compiler (e.g. for inline asm) so we may also want to keep both `abi_required_features` and this new concept of "target features that must be consistent across all crates". We could also eventually turn the target modifier into a safety net: if `abi_required_features` violations are a hard error and `-Ctarget-feature` is locked down to reject non-Rust target features, it should be impossible to ever violate the new target modifier check. Cc @Darksonn @workingjubilee

@Darksonn

Rollup merge of #160593 - RalfJung:abi-relevant-target-features, r=davidtwco turn ABI-controlling target features into a target modifier This makes it so that we can mark "internal" target features (which we track as target features in the compiler but do not expose as such to the user) as target modifiers, to be *really* sure that they are set consistently across all targets. For instance, if there was a value for `-Ctarget-cpu` that affected ABI-relevant target features, we'd catch mismatches in the value of that target feature. For now, this just complements the ABI check logic in `abi_required_features`, but I think long-term it might even be able to fully replace that logic. This would, for example, let us check consistency of the SPARC ABI (#160562) without introducing a new variant for `RustcAbi`. OTOH having the ABI represented explicitly is often useful elsewhere in the compiler (e.g. for inline asm) so we may also want to keep both `abi_required_features` and this new concept of "target features that must be consistent across all crates". We could also eventually turn the target modifier into a safety net: if `abi_required_features` violations are a hard error and `-Ctarget-feature` is locked down to reject non-Rust target features, it should be impossible to ever violate the new target modifier check. Cc @Darksonn @workingjubilee

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Aug 5, 2026

rustbot assigned fee1-dead Aug 5, 2026

This comment has been minimized.

Sign in to view

taiki-e reviewed Aug 5, 2026

View reviewed changes

Comment thread compiler/rustc_target/src/target_features.rs Resolved

bjorn3 reviewed Aug 5, 2026

View reviewed changes

Comment thread compiler/rustc_target/src/target_features.rs Resolved

RalfJung force-pushed the sparc branch from c454884 to 5ee14f5 Compare August 5, 2026 13:48

RalfJung mentioned this pull request Aug 5, 2026

sparc: make ABI consistent with clang #160401

Merged

RalfJung commented Aug 5, 2026

View reviewed changes

This comment has been minimized.

Sign in to view

RalfJung force-pushed the sparc branch from 5ee14f5 to e301f22 Compare August 5, 2026 15:06

RalfJung mentioned this pull request Aug 5, 2026

turn ABI-controlling target features into a target modifier #160593

Merged

taiki-e approved these changes Aug 7, 2026

View reviewed changes

RalfJung mentioned this pull request Aug 7, 2026

Expose target_abi = "v8plus" on sparc-unknown-linux-gnu rust-lang/compiler-team#1028

Closed

1 of 3 tasks

rustbot assigned chenyukang and unassigned fee1-dead Aug 9, 2026

rustbot assigned hanna-kruppe and unassigned chenyukang Aug 10, 2026

RalfJung added the S-waiting-on-MCP Status: PR has a compiler MCP and is waiting for the compiler MCP to complete. label Aug 16, 2026

This comment has been minimized.

Sign in to view

add target feature ABI checks for SPARC

e7cadc3

RalfJung force-pushed the sparc branch from e301f22 to e7cadc3 Compare August 17, 2026 09:30

rustbot assigned tgross35 and unassigned hanna-kruppe Aug 27, 2026

tgross35 reviewed Aug 27, 2026

View reviewed changes

tgross35 approved these changes Aug 27, 2026

View reviewed changes

rust-bors Bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 27, 2026

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 18 pull requests #161901

Closed

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 21 pull requests #161905

Closed

JonathanBrouwer mentioned this pull request Aug 28, 2026

Rollup of 21 pull requests #161906

Merged

rust-bors Bot merged commit 30b9a24 into rust-lang:main Aug 28, 2026
13 checks passed

rustbot added this to the 1.100.0 milestone Aug 28, 2026

RalfJung deleted the sparc branch August 29, 2026 21:07

github-actions Bot mentioned this pull request Oct 2, 2026

Toolchain upgrade to nightly-2026-09-25 flux-rs/flux#1803

Merged

Conversation

RalfJung commented Aug 5, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Aug 5, 2026

Uh oh!

rustbot commented Aug 5, 2026

Uh oh!

This comment has been minimized.

RalfJung commented Aug 5, 2026

Uh oh!

Uh oh!

Uh oh!

RalfJung Aug 5, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

This comment has been minimized.

fee1-dead commented Aug 9, 2026

Uh oh!

chenyukang commented Aug 10, 2026

Uh oh!

hanna-kruppe commented Aug 11, 2026

Uh oh!

This comment has been minimized.

rustbot commented Aug 17, 2026

Uh oh!

rustbot commented Aug 17, 2026

Uh oh!

jonathanpallant commented Aug 27, 2026

Uh oh!

RalfJung commented Aug 27, 2026

Uh oh!

RalfJung commented Aug 27, 2026

Uh oh!

RalfJung commented Aug 27, 2026

Uh oh!

rustbot commented Aug 27, 2026

Uh oh!

tgross35 Aug 27, 2026 • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

RalfJung Aug 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgross35 left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rust-bors Bot commented Aug 27, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

10 participants

RalfJung commented Aug 5, 2026 •

edited by rustbot

Loading

RalfJung Aug 5, 2026 •

edited by rustbot

Loading

tgross35 Aug 27, 2026 •

edited by rustbot

Loading

RalfJung Aug 27, 2026 •

edited

Loading

tgross35 left a comment •

edited by rustbot

Loading