std_detect: support detecting more features on aarch64 Windows
Wires `IsProcessorFeaturePresent` calls for the `PF_ARM_*` constants exposed in Windows SDK 26100 (Windows 11 24H2), plus an architectural derivation for `rdm`. All eight feature names have been stable in `is_aarch64_feature_detected!` on Linux/Darwin/BSD since Rust 1.60 — this brings the Windows backend to parity.
| Feature | Source on Windows |
|---|---|
| `fp16` | `PF_ARM_V82_FP16_INSTRUCTIONS_AVAILABLE` (value 67) |
| `i8mm` | `PF_ARM_V82_I8MM_INSTRUCTIONS_AVAILABLE` (value 66) |
| `bf16` | `PF_ARM_V86_BF16_INSTRUCTIONS_AVAILABLE` (value 68) |
| `sha3` | `PF_ARM_SHA3` (value 64) **AND** `PF_ARM_SHA512` (value 65) |
| `lse2` | `PF_ARM_LSE2_AVAILABLE` (value 62) |
| `f32mm` | `PF_ARM_SVE_F32MM_INSTRUCTIONS_AVAILABLE` (value 58) |
| `f64mm` | `PF_ARM_SVE_F64MM_INSTRUCTIONS_AVAILABLE` (value 59) |
| `rdm` | derived from `PF_ARM_V82_DP` (see below) |
`PF_ARM_SVE_F32MM` / `PF_ARM_SVE_F64MM` (values 58 / 59) were already added as commented-out placeholders in rust-lang/stdarch#1749 — they have direct stable Feature mappings (`f32mm`, `f64mm`), unlike their sibling values 52 / 53 / 57 (`SVE_BF16`, `SVE_EBF16`, `SVE_I8MM`) which have no SVE-specific stdarch Feature name and remain commented for that reason.
`sha3` requires both `PF_ARM_SHA3` (FEAT_SHA3) and `PF_ARM_SHA512` (FEAT_SHA512), matching the existing convention from rust-lang/stdarch#1749 where `sve2-aes` is set only when both `PF_ARM_SVE_AES` and `PF_ARM_SVE_PMULL128` are present.
### `rdm` derivation
There is no `PF_ARM_RDM_*` constant; Microsoft has never defined one. We derive it from `PF_ARM_V82_DP_INSTRUCTIONS_AVAILABLE` (FEAT_DotProd) via the following architectural chain:
1. FEAT_DotProd is an optional v8.2-A feature, so its presence implies the core implements at least v8.1-A.
2. Per Arm ARM K.a §D17.2.91: *"In an ARMv8.1 implementation, if FEAT_AdvSIMD is implemented, FEAT_RDM is implemented."*
3. AdvSIMD is universally implemented on every Windows-on-ARM SKU.
4. Therefore: DotProd ⇒ v8.1-A baseline + AdvSIMD ⇒ FEAT_RDM.
This is the same derivation .NET 10 uses, with comment cited verbatim ([dotnet/runtime PR 109493](https://github.com/dotnet/runtime/pull/109493), shipped in v10.0.0 at [`src/native/minipal/cpufeatures.c`](https://github.com/dotnet/runtime/blob/v10.0.0/src/native/minipal/cpufeatures.c)):
> *"IsProcessorFeaturePresent does not have a dedicated flag for RDM, so we enable it by implication.
> 1) DP is an optional instruction set for Armv8.2, which may be included only in processors implementing at least Armv8.1.
> 2) Armv8.1 requires RDM when AdvSIMD is implemented, and AdvSIMD is a baseline requirement of .NET.
> Therefore, by documented standard, DP cannot exist here without RDM. In practice, there is only one CPU supported by Windows that includes RDM without DP, so this implication also has little practical chance of a false negative."*
The "one CPU with RDM without DP" trade-off applies equally to us: we accept a possible false negative on that single SKU rather than introducing a more aggressive heuristic.
### Tests
Adds `println!` lines to the existing `aarch64_windows()` test in `library/std_detect/tests/cpu-detection.rs` for each newly-detected feature, mirroring the existing single-line pattern. No structural assertions added.
### Scope
Stable feature names only. The unstable SME family (`sme`, `sme2`, `sme2p1`, `sme_*`, `ssve_fp8*`) and other unstable additions tracked under rust-lang/rust#127764 are intentionally out of scope here to keep this PR minimal — happy to do a follow-up.
### References
- Tracking issue: rust-lang/rust#127764 (`stdarch_aarch64_feature_detection`)
- Precedent: rust-lang/stdarch#1749 (taiki-e, merged 2025-03-24) — added the SVE constants this builds on
- MS docs: [`IsProcessorFeaturePresent`](https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-isprocessorfeaturepresent) — full PF_ARM_* table
r? @Amanieu
cc @taiki-e (author of rust-lang/stdarch#1749, would appreciate your eyes on the `rdm` inference)
@rustbot label +T-libs +O-windows +O-ARM
Wire IsProcessorFeaturePresent for the PF_ARM_* constants exposed in
Windows SDK 26100 (Win11 24H2):
fp16 PF_ARM_V82_FP16_INSTRUCTIONS_AVAILABLE (67)
i8mm PF_ARM_V82_I8MM_INSTRUCTIONS_AVAILABLE (66)
bf16 PF_ARM_V86_BF16_INSTRUCTIONS_AVAILABLE (68)
sha3 PF_ARM_SHA3 (64) AND PF_ARM_SHA512 (65)
lse2 PF_ARM_LSE2_AVAILABLE (62)
f32mm PF_ARM_SVE_F32MM_INSTRUCTIONS_AVAILABLE (58)
f64mm PF_ARM_SVE_F64MM_INSTRUCTIONS_AVAILABLE (59)
Also derive `rdm` from FEAT_DotProd. There is no PF_ARM_RDM_* constant;
FEAT_DotProd is an optional v8.2-A feature only present on cores that
implement at least v8.1-A, and v8.1-A with AdvSIMD mandates FEAT_RDM
(Arm ARM K.a §D17.2.91). AdvSIMD is universal on Windows-on-ARM. See
PR description for full rationale and .NET 10 precedent.
All eight feature names have been stable in `is_aarch64_feature_detected!`
on Linux/Darwin/BSD since Rust 1.60.
They were introduced back when std_detect was a standalone crate
published to crates.io. The motivation for std_detect_dlsym_getauxval
was to allow using getauxval without dlopen when statically linking
musl, which we now unconditionally do for musl. And for
std_detect_file_io to allow no_std usage, which std_detect now supports
even with that feature enabled as it directly uses libc. This also
prevents accidentally disabling runtime feature detection when using
cargo build -Zbuild-std -Zbuild-std-features=
Stabilize 29 RISC-V target features (`riscv_ratified_v2`)
This commit stabilizes RISC-V target features with following constraints:
* Describes a ratified extension.
* Implemented on Rust 1.88.0 or before.
Waiting for four+ version cycles seems sufficient.
* Does not disrupt current rustc's target feature (cf. rust-lang/rust#140570) + ABI (cf. rust-lang/rust#132618) handling.
It excludes `E` and all floating point-arithmetic extensions. The `Zfinx` family does not involve floating point registers but not stabilizing for now to avoid possible confusion between the `F` extension family.
* Not vector-related (floating point and integer).
While integer vector subsets should not cause any ABI issues (as they don't use ABI-dependent floating point registers), we need to discuss before stabilizing them.
* Supported by the lowest LLVM version supported by rustc (LLVM 20).
List of target features to be stabilized:
1. `b`
2. `za64rs` (no-RT)
3. `za128rs` (no-RT)
4. `zaamo`
5. `zabha`
6. `zacas`
7. `zalrsc`
8. `zama16b` (no-RT)
9. `zawrs`
10. `zca`
11. `zcb`
12. `zcmop`
13. `zic64b` (no-RT)
14. `zicbom`
15. `zicbop` (no-RT)
16. `zicboz`
17. `ziccamoa` (no-RT)
18. `ziccif` (no-RT)
19. `zicclsm` (no-RT)
20. `ziccrse` (no-RT)
21. `zicntr`
22. `zicond`
23. `zicsr`
24. `zifencei`
25. `zihintntl`
26. `zihintpause`
27. `zihpm`
28. `zimop`
29. `ztso`
Of which, 20 of them (29 minus 9 "no-RT" target features) support runtime detection through `std::arch::is_riscv_feature_detected!()`.
Corresponding PR for the Reference: rust-lang/reference#1987
std-detect: improve detect macro docs
Specifically, document that the detect macros expand to `true` when the feature is statically enabled.
Now that we have a bunch of these macros, perhaps we should streamline further how they are documented?
r? ``@Amanieu``
This commit stabilizes RISC-V target features with following constraints:
* Describes a ratified extension.
* Implemented on Rust 1.88.0 or before.
Waiting for four+ version cycles seems sufficient.
* Does not disrupt current rustc's target feature + ABI handling.
It excludes "E" and all floating point-arithmetic extensions.
"Zfinx" family does not involve floating point registers but
not stabilizing for now to avoid possible confusion between
the "F" extension family.
* Not vector-related (floating point and integer).
While integer vector subsets should not cause any ABI issues
(as they don't use ABI-dependent floating point registers),
we need to discuss before stabilizing them.
* Supported by the lowest LLVM version supported by rustc (LLVM 20).
List of target features to be stabilized:
1. "b"
2. "za64rs" (no-RT)
3. "za128rs" (no-RT)
4. "zaamo"
5. "zabha"
6. "zacas"
7. "zalrsc"
8. "zama16b" (no-RT)
9. "zawrs"
10. "zca"
11. "zcb"
12. "zcmop"
13. "zic64b" (no-RT)
14. "zicbom"
15. "zicbop" (no-RT)
16. "zicboz"
17. "ziccamoa" (no-RT)
18. "ziccif" (no-RT)
19. "zicclsm" (no-RT)
20. "ziccrse" (no-RT)
21. "zicntr"
22. "zicond"
23. "zicsr"
24. "zifencei"
25. "zihintntl"
26. "zihintpause"
27. "zihpm"
28. "zimop"
29. "ztso"
Of which, 20 of them (29 minus 9 "no-RT" target features) support
runtime detection through `std::arch::is_riscv_feature_detected!()`.
Now that this feature has a standard identifier, Darwin has started exposing it accordingly, in addition to the existing less-standard way. Check both, and enable the `crc` feature if either identifier for it is present to ensure backwards and forwards compatibility.
std_detect: RISC-V: implement implication to "C"
Just like we implemented relatively complex rules to imply other extensions **from** "C" (and some others), this commit implements implication **to** the "C" extension from others, complying the following text in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations (*not* in this implementation) can (currently) imply the "C" extension.
Note: this is a `std_detect` change and not main target feature handling.
`std_detect`: Use `rustc-std-workspace-*` to pull in `compiler-builtins`
https://github.com/rust-lang/rust/pull/145489 changed `std_detect` to no
longer depend on `cfg-if`, which meant it no longer indirectly pulled in
`rustc-std-workspace-core` via `cfg-if`. That caused it to no longer
depend on `compiler-builtins`.
Change `std_detect` to use `rustc-std-workspace-core` and
`rustc-std-workspace-alloc`, to integrate with the rustc workspace. This
also pulls in `compiler-builtins` via `rustc-std-workspace-core`.
Closes: https://github.com/rust-lang/rust/issues/145594
Add runtime detection for APX-F and AVX10
This was missed in rust-lang/rust#139534 and rust-lang/rust#139675
`@rustbot` label O-x86_64 O-x86_32 A-target-feature
r? `@Amanieu`
std_detect: RISC-V platform guide documentation
This is practically a revert of a revert, making the commit e907456b2e10622ccd854a3bba8d02ce170b5dbb on `stdarch` come around again with minor fixes, enhancements and adjustments.
An excerpt from the original commit message follows:
Since there's no architectural feature detection on RISC-V (unlike `CPUID` on x86 architectures and some system registers on Arm/AArch64), runtime feature detection entirely depends on the platform-specific facility.
As a result, availability of each feature heavily depends on the platform and its version.
To help users make a decision for feature checking on a RISC-V system, this commit adds a platform guide with minimum supported platform versions.
https://github.com/rust-lang/rust/pull/145489 changed `std_detect` to no
longer depend on `cfg-if`, which meant it no longer indirectly pulled in
`rustc-std-workspace-core` via `cfg-if`. That caused it to no longer
depend on `compiler-builtins`.
Change `std_detect` to use `rustc-std-workspace-core` and
`rustc-std-workspace-alloc`, to integrate with the rustc workspace. This
also pulls in `compiler-builtins` via `rustc-std-workspace-core`.
Closes: https://github.com/rust-lang/rust/issues/145594
Just like we implemented relatively complex rules to imply other extensions
**from** "C" (and some others), this commit implements implication
**to** the "C" extension from others, complying the following text
in the ISA Manual (although there's no direct imply/depend references).
> The C extension is the superset of the following extensions:
>
> - Zca
> - Zcf if F is specified (RV32 only)
> - Zcd if D is specified
This is formally verified so that no other extension combinations
(*not* in this implementation) can (currently) imply the "C" extension.
Migrate the standard library from using the external `cfg_if` crate to
using the now-built-in `cfg_select` macro.
This does not yet eliminate the dependency from
`library/std/Cargo.toml`, because while the standard library itself no
longer uses `cfg_if`, it also incorporates the `backtrace` crate, which
does.
Migration assisted by the following vim command (after selecting the
full `cfg_if!` invocation):
```
'<,'>s/\(cfg_if::\)\?cfg_if/cfg_select/ | '<,'>s/^\( *\)} else {/\1}\r\1_ => {/c | '<,'>s/^\( *\)} else if #\[cfg(\(.*\))\] /\1}\r\1\2 => /e | '<,'>s/if #\[cfg(\(.*\))\] {/\1 => {/e
```
This is imperfect, but substantially accelerated the process. This
prompts for confirmation on the `} else {` since that can also appear
inside one of the arms. This also requires manual intervention to handle
any multi-line conditions.
This is practically a revert of a revert, making the
commit e907456b2e10622ccd854a3bba8d02ce170b5dbb on `stdarch` come around
again with minor fixes, enhancements and adjustments.
An excerpt from the original commit message follows:
Since there's no architectural feature detection on RISC-V (unlike `CPUID`
on x86 architectures and some system registers on Arm/AArch64), runtime
feature detection entirely depends on the platform-specific facility.
As a result, availability of each feature heavily depends on the platform
and its version.
To help users make a decision for feature checking on a RISC-V system, this
commit adds a platform guide with minimum supported platform versions.
Jonathan Brouwer