Tracking Issue for sparc_target_feature

[taiki-e]

This is a tracking issue for SPARC architecture specific part of #44839 (RFC 2045 (rust-lang/rfcs#2045)).
The feature gate for the issue is #![feature(sparc_target_feature)].

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

Steps

• Implementation Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file #132552
• Stabilization PR (see instructions on rustc-dev-guide)

Unresolved Questions

• Behavior of v8plus target feature is LLVM version dependent until LLVM 20 becomes minimal LLVM version (Our 32-bit Sparc handling isn't quite correct yet #132585 (comment))
• Enabling v8plus target feature without v9 target feature should be rejected. (AFAIK, there is no existing mechanism to represent this.)
  

  rust/tests/ui/abi/sparcv8plus.rs

  Lines 37 to 39 in c059eb7

  	// FIXME: should be rejected
  	#[cfg(all(target_feature = "v8plus", not(target_feature = "v9")))]
  	compile_error!("+v8plus,-v9 (FIXME)");

  
  Or, enable v9 target feature automatically when v8plus target feature enabled.

Implementation history

• v9, v8plus, leoncasa: Add v9, v8plus, and leoncasa target feature to sparc and use v8plus in create_object_file #132552

---

@rustbot label +O-SPARC +A-target-feature

[RalfJung]

Enabling v8plus target feature without v9 target feature should be rejected.

We could just represent this as a dependency, i.e., enabling v8plus will automatically enable v9 and disabling v9 will disable v8plus. Would that not be correct?

[taiki-e]

Enabling v8plus target feature without v9 target feature should be rejected.

We could just represent this as a dependency, i.e., enabling v8plus will automatically enable v9 and disabling v9 will disable v8plus. Would that not be correct?

That's Clang 19's behavior and doesn't match with Clang 20+ and GCC. See #132585 (comment):

• LLVM 18 always uses EM_SPARC (code)
• LLVM 19 uses EM_SPARC32PLUS if the v9 feature (which is also a feature that indicates whether certain instructions are available) is enabled, otherwise EM_SPARC (code)
• LLVM 20 (unreleased) uses EM_ SPARC32PLUS if the v8plus feature (which is an independent feature not tied to any other feature) is enabled, otherwise EM_SPARC (code)

The behavior of LLVM 20 is consistent with that of GCC (that -mcpu=v9 does not imply -mv8plus), and I think eventually we will need to match it. (See #132552 (comment) for the motivation for this behavior.)

[beetrees]

Having v9 feature dependency of v8plus isn't the same as Clang 19: it would still be possible to have v9 enabled and v8plus, it just wouldn't be possible to have v8plus enabled but v9 disabled.

[taiki-e]

Oh, sorry, I misunderstood the proposal as suggesting behavior similar to Clang 19.

[RalfJung]

We are already consistent with LLVM 20 clang, aren't we? We just forward v8plus and v9 to LLVM independently. <#160562> is dealing with the ABI so once that lands hopefully ABI should not be an issue any more.

[RalfJung]

FWIW we can also "tie" features together, where we emit an error if they are not in sync (rather than implicitly enabling more features via a dependency). We do that for some ARM features.