Skip to content

Tracking Issue for stdarch_s390x_feature_detection #135413

Closed

Description

@folkertdev

Feature gate: #![feature(stdarch_s390x_feature_detection)]

This is a tracking issue for SystemZ target feature detection.

Public API

// std::arch

macro_rules! is_s390x_feature_detected { .. }

Steps / History

Unresolved Questions

  • None yet.

@rustbot label O-SystemZ

Footnotes

  1. https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html ↩

Activity

  1. added
    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFC
    T-libs-api[DEPRECATED; DO NOT USE]
    on Jan 12, 2025
  2. added a commit that references this issue on Mar 16, 2025
  3. added a commit that references this issue on Mar 16, 2025
  4. added a commit that references this issue on Mar 19, 2025
  5. uweigand commented on May 16, 2025

    @uweigand
    Contributor

    The new machines IBM z17 and IBM LinuxONE Emperor 5 were recently announced. These machines implement the arch15 level of the z/Architecture. Support for this has been added to LLVM here: llvm/llvm-project@8424bf2

    This architecture level provides a number of new architecture features. LLVM supports the following:

      "miscellaneous-extensions-4"
      "vector-enhancements-3"
      "vector-packed-decimal-enhancement-3"
      "message-security-assist-extension12"
      "concurrent-functions"
    

    It would be good to add (a subset of?) those to the list of features supported by Rust as well.

    However, the Linux kernel maintainers decided to no longer provide new HWCAP bits for these features. Instead, users are encouraged to determine presence of those features via the STFLE instruction. This was done to avoid running out of HWCAP bits - new bits are now only allocated for features that require kernel support in addition to hardware support (as is currently the case for the "vector" feature).

    This means the Rust implementation should be changed to primarily use STFLE to detect features, but still consult HWCAP in addition for those features that require kernel support (i.e. "vector" only right now). As an additional benefit, this would also allow properly detecting older features that do not have HWCAP bits - most notably the various "miscellaneous-extensions-N" features would be important to detect (and maybe some others).

    Is this feature the proper place to discuss this, or should I open another one?
    FYI @folkertdev @taiki-e @cuviper @fneddy

  6. added a commit that references this issue on Jun 4, 2025
  7. added a commit that references this issue on Jun 4, 2025
  8. added a commit that references this issue on Jun 4, 2025
  9. added a commit that references this issue on Nov 6, 2025
  10. added a commit that references this issue on Nov 6, 2025
  11. added 2 commits that reference this issue on Nov 7, 2025
  12. added 2 commits that reference this issue on Nov 7, 2025
  13. added a commit that references this issue on Nov 8, 2025
  14. added a commit that references this issue on Nov 9, 2025
  15. added a commit that references this issue on Nov 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    C-tracking-issueCategory: An issue tracking the progress of sth. like the implementation of an RFCO-SystemZTarget: SystemZ processors (s390x)T-libs-api[DEPRECATED; DO NOT USE]

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions