Stabilize s390x vector target feature and is_s390x_feature_detected! macro

[folkertdev]

closes #145649
closes #135413
cc: #130869
reference PR: rust-lang/reference#1972

Stabilization report

Summary

This PR stabilizes the following s390x target features:

• vector
• vector-enhancements-1
• vector-enhancements-2
• vector-enhancements-3
• vector-packed-decimal
• vector-packed-decimal-enhancement
• vector-packed-decimal-enhancement-2
• vector-packed-decimal-enhancement-3
• nnp-assist
• miscellaneous-extensions-2
• miscellaneous-extensions-3
• miscellaneous-extensions-4

Additionally, it stabilizes the std::arch::is_s390x_feature_detected! macro itself and stably accepts the target features listed above.

Tests & ABI details

Only the vector target feature changes the ABI, much like e.g. avx2 it will, depending on the ABI, pass vector types in vector registers. This behavior is tested extensively:

• tests/assembly-llvm/s390x-vector-abi.rs
• tests/codegen-llvm/s390x-simd.rs
• tests/ui/abi/simd-abi-checks-s390x.rs

The remaining features don't influence the ABI, they only influence instruction selection. In stdarch we test that the expected instructions are in fact generated when the target feature is enabled.

Implementation history

For is_s390x_feature_detected!:

• add is_s390x_feature_detected stdarch#1699
• expose is_s390x_feature_detected! from std::arch #138275
• s390x_is_feature_detected!: detect more features stdarch#1720
• s390x: z17 target feature detection stdarch#1832

For vector and friends

• rustc_target: add known safe s390x target features #127506
• add more s390x target features #135630
• add s390x z17 target features #141250

Unresolved questions

There is a fixme in tests/ui/abi/simd-abi-checks-s390x.rs:

// FIXME: +soft-float itself doesn't set -vector
//@[z13_soft_float] compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float
//@[z13_soft_float] needs-llvm-components: systemz

I'm not sure whether that blocks stabilization?

---

The implementation first extracts the listed target features into their own s390x_target_feature_vector rust feature, and then stabilizes that. best reviewed commit-by-commit

r? @Amanieu
cc @uweigand @taiki-e

[rustbot]

stdarch is developed in its own repository. If possible, consider making this change to rust-lang/stdarch instead.

cc @Amanieu, @folkertdev, @sayantn

[Amanieu]

@rfcbot merge

[rfcbot]

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @scottmcm
• @the8472
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

[Amanieu]

There is a fixme in tests/ui/abi/simd-abi-checks-s390x.rs:

// FIXME: +soft-float itself doesn't set -vector
//@[z13_soft_float] compile-flags: --target s390x-unknown-linux-gnu -C target-cpu=z13 -C target-feature=-vector,+soft-float
//@[z13_soft_float] needs-llvm-components: systemz

I'm not sure whether that blocks stabilization?

I think this is fine since we don't have a soft-float s390x target and don't expose the soft-float feature. However we would want to re-visit this if we ever get such a target.

[RalfJung]

+soft-float doesn't usually disable anything, it's about the ABI entirely orthogonal to which registers are available. So I think that FIXME should just be removed.

[uweigand]

On s390x, in LLVM (and GCC), the +soft-float feature does in fact disable any use of floating-point (or vector) registers, and therefore implicitly any use of instructions requiring these features, which implies e.g. fully disabling the +vector feature. This is in addition to the ABI changes (which are of course necessary as the default ABI makes use of floating-point and vector registers).

In LLVM in particular, the back-end does actually implement that +soft-float implies -vector. I guess the above FIXME is about making sure this matches what Rust itself assumes? Either way, I think resolution of this can wait until we're trying to expose the feature.

In practice, the only user of +soft-float on our platform would be the Linux kernel. Here, we don't really care about the ABI aspect (the kernel does not use any floating-point or vector data types), but we do care about the guarantee that generated code will not touch floating-point or vector registers.

[traviscross]

We've revised and approved the Reference PR, so this will be good to go on that front when FCP completes.

• specify s390x target features reference#1972

(cc @rust-lang/lang-docs)

On the lang side, this looks good to me.

@rfcbot reviewed

[RalfJung]

The linux kernel needs a separate target that has soft-float set. We cannot support such ABI-changing target features with -Ctarget-features. (Also, such target target features are kind of a hack in LLVM. The proper solution is to do what the ARM32 and riscv targets do and explicitly set the ABI. Sadly very few targets do this the right way.)

[bors]

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

[taiki-e]

As for z17-related target features, we might want to wait until LLVM 20 becomes the minimum external LLVM version (#145071). UPDATE: #145071 has been merged.

As for the soft-float target feature, I don't think we need to worry about it here. It is not supported on rustc's target feature interface (rustc emits a "unknown and unstable feature" warning that says "use of this feature might be unsound" when it is used), and as discussed in the vector ABI PR (#131586 (comment)), it will eventually be rejected for setting via -Ctarget-feature. For the Linux kernel, a bare-metal soft-float (custom or new builtin) target should be used.

[nikomatsakis]

@rfcbot reviewed

[tmandry]

I'm nervous about side effects of the extern "C" ABI changing based on target feature, but as @Amanieu noted that's preexisting in the C ABI.

@rfcbot reviewed

[ehuss]

@bors retry
bot opened the tree unexpectedly

[rust-log-analyzer]

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)

spellchecking files
building external tool typos from package [email protected]
finished building tool typos
npm WARN deprecated [email protected]: < 24.10.2 is no longer supported
npm ERR! code 127
npm ERR! git dep preparation failed
npm ERR! command /node/bin/node /node/lib/node_modules/npm/bin/npm-cli.js install --force --cache=/home/user/.npm --prefer-offline=false --prefer-online=false --offline=false --no-progress --no-save --no-audit --include=dev --include=peer --include=optional --no-package-lock-only --no-dry-run
npm ERR! npm WARN using --force Recommended protections disabled.
npm ERR! npm WARN deprecated [email protected]: This module is not supported, and leaks memory. Do not use it. Check out lru-cache if you want a good and tested way to coalesce async requests by a key value, which is much more comprehensive and powerful.
npm ERR! npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm ERR! npm WARN deprecated [email protected]: Glob versions prior to v9 are no longer supported
npm ERR! npm WARN deprecated [email protected]: This functionality has been moved to @npmcli/fs
npm ERR! npm WARN deprecated [email protected]: Package no longer supported. Contact Support at https://www.npmjs.com/support for more info.
npm ERR! npm WARN deprecated [email protected]: This package is no longer supported. Please use @npmcli/package-json instead.
npm ERR! npm WARN deprecated [email protected]: This package is no longer supported.
npm ERR! npm ERR! code 127
npm ERR! npm ERR! path /home/user/.npm/_cacache/tmp/git-cloneXXXXXXb3cq7j/node_modules/rollup
npm ERR! npm ERR! command failed
npm ERR! npm ERR! command sh -c patch-package
npm ERR! npm ERR! sh: 1: patch-package: not found
npm ERR! 
npm ERR! npm ERR! A complete log of this run can be found in: /home/user/.npm/_logs/2025-11-07T21_56_22_646Z-debug-0.log

npm ERR! A complete log of this run can be found in: /home/user/.npm/_logs/2025-11-07T21_56_15_328Z-debug-0.log
npm install did not exit successfully
tidy [extra_checks]: IO error: npm install returned exit code exit status: 127
tidy [extra_checks]: FAIL
tidy: The following check failed: extra_checks
Command `/checkout/obj/build/x86_64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/x86_64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 /node/bin/npm --extra-checks=py,cpp,js,spellcheck` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1549:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1279:29

Command has failed. Rerun with -v to see more details.
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Build completed unsuccessfully in 0:03:00
  local time: Fri Nov  7 21:56:40 UTC 2025
  network time: Fri, 07 Nov 2025 21:56:40 GMT
##[error]Process completed with exit code 1.

[uweigand]

Hi @folkertdev, thanks for pushing this! Unfortunately, since this PR was merged, our CI runs are now failing with:

error[E0658]: use of unstable library feature `s390x_target_feature`
   --> /home/stefansf/devel/dailyrust-workdir/rust/library/std_detect/src/detect/macros.rs:10:13
    |
  4 |   macro_rules! detect_feature {
[...]
 88 | |         }
    | |_________- in this expansion of `is_s390x_feature_detected!` (#1)
    |
   ::: library/std/tests/run-time-detect.rs:145:45
    |
145 |       println!("transactional-execution: {}", is_s390x_feature_detected!("transactional-execution"));
    |                                               ----------------------------------------------------- in this macro invocation (#1)
    |
    = note: see issue #44839 <https://github.com/rust-lang/rust/issues/44839> for more information
    = help: add `#![feature(s390x_target_feature)]` to the crate attributes to enable
    = note: this compiler was built on 2025-11-12; consider upgrading it if it is out of date

It seems to me the test now assumes is_s390x_feature_detected is stable, which it is - but not for all individual features that might be tested. In particular, transactional-execution is not stable. How is that supposed to work?

[folkertdev]

Ah, the test file needs to enable the #![feature(s390x_target_feature)] now, can you check that this change works?

diff --git a/library/std/tests/run-time-detect.rs b/library/std/tests/run-time-detect.rs
index b2c3d0d3f9f..be2980f7326 100644
--- a/library/std/tests/run-time-detect.rs
+++ b/library/std/tests/run-time-detect.rs
@@ -16,6 +16,7 @@
     all(target_arch = "powerpc64", target_os = "linux"),
     feature(stdarch_powerpc_feature_detection)
 )]
+#![cfg_attr(all(target_arch = "s390x", target_os = "linux"), feature(s390x_target_feature))]
 
 #[test]
 #[cfg(all(target_arch = "arm", any(target_os = "linux", target_os = "android")))]

[uweigand]

can you check that this change works?

I've started a run to verify. Thanks!