Repository navigation
Rollup of 6 pull requests - #163763
Closed
JonathanBrouwer wants to merge 17 commits into
Closed
Rollup of 6 pull requests#163763JonathanBrouwer wants to merge 17 commits into
JonathanBrouwer wants to merge 17 commits into
Conversation
Previously, the calling convention code would not register align 16-byte scalars to even/odd register pairs. It seems like GCC does not differentiate between integer and floating point scalars when calculating whether a scalar is aligned. To our understanding, the MIPS n64 ABI [1] would require doing so for integer and floating point parameters respectively [2], but GCC violates the specification here and will happily pass an f128 in an odd-even floating point register pair and therefore sometimes shift following integer arguments due to unnecessary (if the spec is to be believed) inserted integer padding. [1]: https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf#page=20 [2]: "This requires that they be passed in even-odd floating point register pairs, even if doing so requires skipping a register parameter"
`MOVDIR64B` and `MOVDIRI` (direct stores of 64 bytes and of a 32/64-bit integer) are standalone x86 CPUID features, on Intel Tiger Lake and Sapphire Rapids onwards and AMD Zen 5, that are not part of any psABI microarchitecture level. They need their own unstable target features, gated behind `movdir64b_target_feature` and `movdiri_target_feature`. This is the compiler half of exposing the `_movdir64b`, `_directstoreu_u32` and `_directstoreu_u64` intrinsics; the stdarch half is blocked on this landing. Also update the check-cfg/target_feature UI test reference, which enumerates the full set of valid target features.
Wire up runtime detection for both features: add them to the `is_x86_feature_detected!` feature list (gated on `movdir64b_target_feature` and `movdiri_target_feature`), enable them from CPUID leaf 7 ECX bits 28 and 27, and add them to the std_detect x86-specific dump test.
…[T; N], &[T; N] and &mut [T; N]" Revert "fix stability attributes for VecDeque PartialEq impls" This reverts commit 9942d36. Revert "update VecDeque PartialEq stability metadata" This reverts commit 3d3f2f8. Revert "update assert-ne-no-invalid-help-issue-146204.stderr for VecDeque PartialEq output" This reverts commit 8cdd010. Revert "resolve too_generic_eval_ice stderr conflict" This reverts commit b50d79a. Revert "alloc: make VecDeque partial equality symmetric with vec/slice/array" This reverts commit 835975a.
Rip out old solver coherence cc [#t-types/call-for-participation > rip out old solver coherence support](https://rust-lang.zulipchat.com/#narrow/channel/618216-t-types.2Fcall-for-participation/topic/rip.20out.20old.20solver.20coherence.20support/with/613938355) Probably best reviewed commit-by-commit with ignore-whitespace. rust-lang#160668 replaced the last remaining place where old solver was still used by default in coherence with new solver. This PR removes code that was only used during coherence by the old solver, so now new-solver coherence is the *only* way to do coherence. So we don't confuse users, passing `-Znext-solver=coherence` and `=no` now do the exact same thing. We also remove tracking intercrate ambiguity causes, since afaict the new solver uses a completely different path. Everything else is either removing code that is now unreachable, or removing a condition that is now always true. r? lcnr
…ouxu regression test for async handler normalization ICE Closes rust-lang#141850
…ignment, r=folkertdev callconv: mips64: Match GCC for alignment of 16-byte scalars Previously, the calling convention code would not register align 16-byte scalars to even/odd register pairs. It seems like GCC does not differentiate between integer and floating point scalars when calculating whether a scalar is aligned. To our understanding, the MIPS n64 ABI [^1] would require doing so for integer and floating point parameters respectively [^2], but GCC violates the specification here and will happily pass an f128 in an odd-even floating point register pair and therefore sometimes shift following integer arguments due to unnecessary (if the spec is to be believed) inserted integer padding. [^1]: https://web.archive.org/web/20160121005457/http://techpubs.sgi.com/library/manuals/2000/007-2816-005/pdf/007-2816-005.pdf#page=20 [^2]: "This requires that they be passed in even-odd floating point register pairs, even if doing so requires skipping a register parameter" Fixes rust-lang#161679 r? folkertdev cc @beetrees
…=folkertdev
Add the `movdir64b` and `movdiri` x86 target features
Adds the unstable `movdir64b` and `movdiri` x86 target features, gated behind `#![feature(movdir64b_target_feature)]` and `#![feature(movdiri_target_feature)]`, and runtime detection with `is_x86_feature_detected!("movdir64b")` / `is_x86_feature_detected!("movdiri")` (CPUID.(EAX=7,ECX=0):ECX[28] and ECX[27]).
`MOVDIR64B` moves 64 bytes from memory to a 64-byte aligned destination as a single direct store; `MOVDIRI` stores a 32- or 64-bit integer as a direct store. Both are on Intel Tiger Lake / Alder Lake and later, Sapphire Rapids and later Xeons, and AMD Zen 5. They're standalone CPUID features that aren't part of any psABI microarchitecture level, so they need their own feature flags.
**This is the compiler half of a two-PR feature, like `clflushopt` in rust-lang#157098.** The `_movdir64b`, `_directstoreu_u32` and `_directstoreu_u64` intrinsics (rust-lang/stdarch#2239) can't compile until these target features exist, so the stdarch PR is blocked on this one merging and syncing into stdarch's pinned toolchain.
- Tracking issue: rust-lang#163741
- Unblocks intrinsics: rust-lang/stdarch#2239
Today the only way to emit these instructions from Rust is `asm!`, which also hides them from LLVM: a copy loop through `llvm.x86.movdir64b` gets unrolled and the source address becomes a displacement, while the `asm!` version stays one instruction per iteration with both addresses in registers.
`movdir64b` and `movdiri` are LLVM's feature names, so they map 1:1 through `to_llvm_features` with no remap entry. I ran the two new feature-gate tests, `check-cfg/target_feature` and `target-feature/invalid-attribute`, the std_detect tests (which report both features as `true` on a Xeon 6975P-C), and tidy locally on x86_64-pc-windows-msvc.
r? @folkertdev
…leq, r=clarfonthey Revert "implement PartialEq<VecDeque<U>> for Vec<T>, &[T], &mut [T], [T; N], &[T; N] and &mut [T; N]" This should go through FCP. This is a revert so we can do FCP on the actual PR. r? joboet
…cs, r=jonathanbrouwer fix -Z track-diagnostics for errors and lints emitted from rustc_attr_parsing r? @GuillaumeGomez or perhaps @JonathanBrouwer
rustbot
added
A-attributes
Member
Author
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 4, 2026
Rollup of 6 pull requests try-job: dist-various-1 try-job: test-various try-job: test-x86_64-gnu-aux try-job: test-x86_64-msvc-1 try-job: test-aarch64-apple-1 try-job: test-aarch64-apple-2 try-job: test-x86_64-mingw-1 try-job: test-i686-msvc try-job: test-armhf-gnu
JonathanBrouwer
force-pushed
the
rollup-i65nyeL
branch
from
October 4, 2026 17:22
9d2e341 to
ea98840
Compare
This comment has been minimized.
This comment has been minimized.
rust-bors Bot
pushed a commit
that referenced
this pull request
Oct 4, 2026
…uwer Rollup of 6 pull requests Successful merges: - #161491 (Rip out old solver coherence) - #163223 (regression test for async handler normalization ICE) - #163653 (callconv: mips64: Match GCC for alignment of 16-byte scalars) - #163742 (Add the `movdir64b` and `movdiri` x86 target features) - #163752 (Revert "implement PartialEq<VecDeque<U>> for Vec<T>, &[T], &mut [T], [T; N], &[T; N] and &mut [T; N]") - #163755 (fix -Z track-diagnostics for errors and lints emitted from rustc_attr_parsing)
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
Bot
added
S-waiting-on-review
Contributor
|
💔 Test for 33563d2 failed: CI. Failed job:
|
rust-bors
Bot
added
the
S-waiting-on-author
rustbot
removed
the
S-waiting-on-review
Contributor
|
PR #163755, which is a member of this rollup, was unapproved. |
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
9 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Successful merges:
movdir64bandmovdirix86 target features #163742 (Add themovdir64bandmovdirix86 target features)r? @ghost
Create a similar rollup