Repository navigation
Rollup of 9 pull requests - #163767
Merged
Merged
Rollup of 9 pull requests#163767
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.
…`can_continue_expr_unambiguously`
* `can_continue_expr_unambiguously`
* exhaustively match on `AssocOp`
* don't needlessly provide code snippets in comments for ops that are
unproblematic, that's not interesting
* instead, provide an example / explainer for each op that is ambiguous
which is far more relevant
* move it into `rustc_parse` since it's only used there & it's only
tailored towards parse error recovery
* `should_continue_as_assoc_expr`
* it used to match on a `(bool, _)` tuple & execute `AssocOp::from_token`
unconditionally even though all but one branch cared about the bool
being false
* instead, first check `expr_is_complete` and bail out early if it's
false; no need to execute `AssocOp::from_token` unnecessarily or
"bother" the rest of the code with the impossibility of
`expr_is_complete` not holding
* extract the recovery logic into a new
`recover_from_bin_op_after_complete_stmt_expr` that resides in
`expr/diagnostics.rs` to clearly separate what is recovery and what
is actual parsing
* in it check `can_continue_expr_unambiguously` *first* before
special-casing some ops (the `Mul | Sub | …` branch) because it's
more "important"; in any case it's a superset; renders the control
flow & the logic a lot more comprehensible
* rewrite the comments from scratch to make it clear that all of that
"bin op after complete stmt expr" is recovery code only! when I
first came across this function one year ago I was super confused &
briefly worried that typeck was potentially making belated parsing
decisions
* inline it because it's become a single expression
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
Run cg_gcc tests with the correct compiler
Seems like we have been running the tests with the stage 0 compiler all along :surprised: The tests crash with:
```
[BUILD] mini_core
[BUILD] example
[AOT] mini_core_hello_world
warning: the feature `never_type` has been stable since 1.101.0-dev and no longer requires an attribute to enable
--> example/mini_core_hello_world.rs:4:44
|
4 | no_core, unboxed_closures, lang_items, never_type, linkage,
| ^^^^^^^^^^
|
= note: `#[warn(stable_features)]` on by default
thread 'rustc' (1671953) panicked at compiler/rustc_codegen_ssa/src/mir/rvalue.rs:1114:5:
assertion `left == right` failed
left: __int8_t * __attribute__((aligned(8)))
right: void *
stack backtrace:
0: __rustc::rust_begin_unwind
at /rustc/cbae9b4cae2b108f6a3d18cfe6075714bb739463/library/std/src/panicking.rs:679:5
1: core::panicking::panic_fmt
at /rustc/cbae9b4cae2b108f6a3d18cfe6075714bb739463/library/core/src/panicking.rs:80:14
2: core::panicking::assert_failed_inner
at /rustc/cbae9b4cae2b108f6a3d18cfe6075714bb739463/library/core/src/panicking.rs:452:17
3: core::panicking::assert_failed::<gccjit::types::Type, gccjit::types::Type>
at /rustc/cbae9b4cae2b108f6a3d18cfe6075714bb739463/library/core/src/panicking.rs:407:5
4: transmute_scalar<rustc_codegen_gcc::builder::Builder>
5: codegen_transmute_operand<rustc_codegen_gcc::builder::Builder>
at /home/bjorn/rust/compiler/rustc_codegen_ssa/src/mir/rvalue.rs:419:21
6: codegen_rvalue_operand<rustc_codegen_gcc::builder::Builder>
at /home/bjorn/rust/compiler/rustc_codegen_ssa/src/mir/rvalue.rs:625:30
7: codegen_statement<rustc_codegen_gcc::builder::Builder>
at /home/bjorn/rust/compiler/rustc_codegen_ssa/src/mir/statement.rs:37:52
```
I'll need help with resolving that from the cg_gcc side (CC @antoyo).
Fixes: rust-lang#163527
…ouxu regression test for async handler normalization ICE Closes rust-lang#141850
…-dead simplify rustc_log a bit
…eetrees x86: c-variadic functions don't use registers with `-Zregparm` tracking issue: rust-lang#131749 There are lots of other things wrong with the implementation, but that'll require a larger PR (and also GCC and clang currently disagree). May as well just lock this in now. r? beetrees
…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
…oc-expr, r=fee1-dead Parser: Refactor & better document `should_continue_as_assoc_expr` & `can_continue_expr_unambiguously` Whenever I stumbled across `should_continue_as_assoc_expr` I had to very slowly reread its impl because the contained `match` was written in an incredibly convoluted fashion rendering it illegible. Moreover, I always had a hard time figuring out what part of the code was recovery & what actual parsing, esp. since it does indeed save extra diagnostic info in the happy path (proactively). See commit message for details. <sub>(No LLM was or will be used by me during the entire creation process of this PR)</sub>
…=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
rustbot
added
A-testsuite
rustbot
added
the
WG-trait-system-refactor
Member
Author
|
@bors r+ p=5 force |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
This comment has been minimized.
This comment has been minimized.
rust-bors
Bot
added
merged-by-bors
Contributor
This was referenced Oct 4, 2026
Contributor
What is this?This is an experimental post-merge analysis report that shows differences in test outcomes between the merged PR and its parent PR.Comparing f48b3e6 (parent) -> 2822155 (this PR) Test differencesShow 85 test diffsStage 1
Stage 2
Additionally, 39 doctest diffs were found. These are ignored, as they are noisy. Job group index
Test dashboardRun cargo run --manifest-path src/ci/citool/Cargo.toml -- \
test-dashboard 28221559263a3976766cf305940e80e30cf9ba8a --output-dir test-dashboardAnd then open Job duration changes
How to interpret the job duration changes?Job durations can vary a lot, based on the actual runner instance |
Collaborator
|
Finished benchmarking commit (2822155): comparison URL. Overall result: ❌✅ regressions and improvements - please read:Our benchmarks found a performance regression caused by this PR. Next Steps:
@rustbot label: +perf-regression Instruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)Results (primary -1.3%, secondary 1.4%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesResults (secondary -1.8%)A less reliable metric. May be of interest, but not used to determine the overall result above.
Binary sizeThis perf run didn't have relevant results for this metric. Bootstrap: 490.122s -> 489.206s (-0.19%) |
Contributor
|
📌 Perf builds for each rolled up PR:
parent commit: f48b3e61ee In the case of a perf regression, run the following command with the SHAs of each PR you suspect might be the cause: |
Member
Author
|
@rust-timer triage all |
Collaborator
Running triage with 5 benchmarksTriage only executes the benchmarks on rollup members, that were changed significantly on the rollup.
#161491 8e00340 Rip out old solver coherenceInstruction countOur most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. #163533 68c6f7d Run cg_gcc tests with the correct compilerThis perf run didn't have relevant results for the `instruction count` metric.Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)Results (primary 1.3%)A less reliable metric. May be of interest, but not used to determine the overall result above.
CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. #163223 b4dc9ec regression test for async handler normalization ICEThis perf run didn't have relevant results for the `instruction count` metric.Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. #163367 7e4fafd simplify rustc_log a bitThis perf run didn't have relevant results for the `instruction count` metric.Instruction countThis perf run didn't have relevant results for this metric. Max RSS (memory usage)This perf run didn't have relevant results for this metric. CyclesThis perf run didn't have relevant results for this metric. Binary sizeThis perf run didn't have relevant results for this metric. #163622 23d4076 x86: c-variadic functions don't use registers with
|
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
- | - | 0 |
| Improvements ✅ (primary) |
- | - | 0 |
| Improvements ✅ (secondary) |
-1.6% | [-1.6%, -1.6%] | 1 |
| All ❌✅ (primary) | - | - | 0 |
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
#163665 7884eed Parser: Refactor & better document should_continue_as_assoc_expr & can_continue_expr_unambiguously
This perf run didn't have relevant results for the `instruction count` metric.
Instruction count
This perf run didn't have relevant results for this metric.
Max RSS (memory usage)
This perf run didn't have relevant results for this metric.
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
#163742 467a699 Add the movdir64b and movdiri x86 target features
This perf run didn't have relevant results for the `instruction count` metric.
Instruction count
This perf run didn't have relevant results for this metric.
Max RSS (memory usage)
This perf run didn't have relevant results for this metric.
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
#163752 1baa6cb Revert "implement PartialEq<VecDeque> for Vec, &[T], &mut [T], [T; N], &[T; N] and &mut [T; N]"
Instruction count
Our most reliable metric. Used to determine the overall result above. However, even this metric can be noisy.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
- | - | 0 |
| Improvements ✅ (primary) |
-0.1% | [-0.1%, -0.1%] | 1 |
| Improvements ✅ (secondary) |
-0.0% | [-0.1%, -0.0%] | 2 |
| All ❌✅ (primary) | -0.1% | [-0.1%, -0.1%] | 1 |
Max RSS (memory usage)
Results (secondary -1.7%)
A less reliable metric. May be of interest, but not used to determine the overall result above.
| mean | range | count | |
|---|---|---|---|
| Regressions ❌ (primary) |
- | - | 0 |
| Regressions ❌ (secondary) |
- | - | 0 |
| Improvements ✅ (primary) |
- | - | 0 |
| Improvements ✅ (secondary) |
-1.7% | [-1.7%, -1.7%] | 1 |
| All ❌✅ (primary) | - | - | 0 |
Cycles
This perf run didn't have relevant results for this metric.
Binary size
This perf run didn't have relevant results for this metric.
Member
Author
|
Caused by #161491 (comment) |
rustbot
added
the
perf-regression-triaged
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
11 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:
-Zregparm#163622 (x86: c-variadic functions don't use registers with-Zregparm)should_continue_as_assoc_expr&can_continue_expr_unambiguously#163665 (Parser: Refactor & better documentshould_continue_as_assoc_expr&can_continue_expr_unambiguously)movdir64bandmovdirix86 target features #163742 (Add themovdir64bandmovdirix86 target features)r? @ghost
Create a similar rollup