Stabilize sha512, sm3 and sm4 for x86

[sayantn]

This PR stabilizes the feature flag sha512_sm_x86 (tracking issue #126624).

Public API

The 3 x86 target features sha512, sm3 and sm4, and the associated intrinsics in stdarch.

These target features are very specialized, and are only used to signal the presence of the corresponding CPU instruction. They don't have any nontrivial interaction with the ABI (contrary to something like AVX), and serve the only purpose of enabling 10 stdarch intrinsics, all of which have been implemented and propagated to rustc via a stdarch submodule update.

Also, these were added in LLVM17, and as the minimum LLVM required for rustc is LLVM19, we are safe in that front too!

Associated PRs

• Added SHA512, SM3, SM4 target-features and sha512_sm_x86 feature gate #126704
• Add Runtime detection for SHA512, SM3 and SM4 stdarch#1592
• Implement SHA512, SM3 and SM4 intrinsics stdarch#1790
• Remove avx512dq and avx512vl implication for avx512fp16 #140389 (stdarch submodule update)
• Stabilize sha512, sm3 and sm4 intrinsics and runtime detection stdarch#1796 (stabilizing the runtime detection and intrinsics)

As all of the required tasks have been done (adding the target features to rustc, implementing their runtime detection in std_detect and implementing the associated intrinsics in core_arch), these target features can be stabilized now.

cc @rust-lang/lang
cc @rust-lang/libs-api for the intrinsics and runtime detection

I don't think anyone else worked on this feature, so no one else to ping, maybe cc @Amanieu. I will send the reference pr soon.

[rustbot]

⚠️ Warning ⚠️

• Some commits in this PR modify submodules.

[traviscross]

Stabilizing target features are somewhat minimal as far as stabilizations go, but still, this is going to need something more in the way of a stabilization report in the description of this PR. We need some narrative about what we're stabilizing here and a review of the evidence about why it's OK for us to stabilize this now. Have a look at our new template for this in rust-lang/rustc-dev-guide#2219.

Please think too about who else in the Project has worked on this or related things and who might therefore be interested in this, and please ping those people here.

This will also need a PR to the Reference documenting the change, and that should be linked from the stabilization report as well.

@rustbot labels +S-waiting-on-documentation

Please renominate when the stabilization report is available.

[traviscross]

is this okay? Or do I have to give more details?

Thanks for adding the details above. @scottmcm, @RalfJung, @workingjubilee, anything more you want to see for this sort of thing?

[RalfJung]

The main question are indeed ABI concerns, or more generally "is there any potential for problems when mixing code built with and without these target features". It seems the answer to that is "no".

The only other issue I think we had is, "does our minimum LLVM version support these target features".

[sayantn]

@RalfJung updated the text with the minimum llvm version

[traviscross]

Sounds OK to me then. Let's propose FCP.

@rfcbot fcp merge

[rfcbot]

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

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @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.

[traviscross]

@sayantn, do the sha512, sm3, and sm4 names match what is shown in /proc/cpuinfo or some other semi-standard source of flag names?

[sayantn]

I don't know about /proc/cpuinfo, but these names are used by gcc, llvm and Intel, so I would say there should be no confusion about these names

[bors]

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

[tmandry]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[bors]

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

[rust-log-analyzer]

The job aarch64-gnu-llvm-19-2 failed! Check out the build log: (web) (plain)

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

[AOT] issue-59326
##[endgroup]
##[group][AOT] neon
[AOT] neon
warning: unsupported llvm intrinsic llvm.roundeven.v4f32; replacing with trap

warning: 1 warning emitted


thread 'main' panicked at library/core/src/panicking.rs:225:5:
llvm.roundeven.v4f32 is not yet supported.
See https://github.com/rust-lang/rustc_codegen_cranelift/issues/171
Please open an issue at https://github.com/rust-lang/rustc_codegen_cranelift/issues
stack backtrace:
   0: __rustc::rust_begin_unwind
   1: core::panicking::panic_nounwind_fmt
   2: core::panicking::panic_nounwind
   3: core::core_arch::arm_shared::neon::generated::vrndnq_f32
             at /checkout/library/core/src/../../stdarch/crates/core_arch/src/arm_shared/neon/generated.rs:58812:14
   4: neon::test_vrndnq_f32
             at ./example/neon.rs:239:30
   5: neon::main
             at ./example/neon.rs:274:9
   6: <fn() as core::ops::function::FnOnce<()>>::call_once
             at /checkout/library/core/src/ops/function.rs:250:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
thread caused non-unwinding panic. aborting.
"/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools/cg_clif/build/example/neon" exited with status ExitStatus(unix_wait_status(134))
Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:11:10
  local time: Sat May 31 11:54:25 UTC 2025
  network time: Sat, 31 May 2025 11:54:25 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

[sayantn]

The job aarch64-gnu-llvm-19-2 failed! Check out the build log: (web) (plain)
Click to see the possible cause of the failure (guessed by this bot)

cc @bjorn3, iirc you mentioned this in the stdarch PR 😅

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[bors]

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

[sayantn]

I am updating the stdarch submodule in #141964, so I will update this after that merges