Revert #143906

[Kobzol]

This reverts commit 71f0469, reversing changes made to 995ca3e.

Reverts #143906, which was merged in #145043.

It seems like it is causing test failures on CI that block merges (#144787 (comment).

try-job: x86_64-gnu-aux

[rustbot]

r? @thomcc

rustbot has assigned @thomcc.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Kobzol]

@bors try

[rustbot]

The Miri subtree was changed

cc @rust-lang/miri

[rustbot]

⚠️ Warning ⚠️

• There are issue links (such as #123) in the commit messages of the following commits.
  Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.
  • 8fcfbcd

[rust-bors]

⌛ Trying commit 8fcfbcd with merge 3f642d9…

To cancel the try build, run the command @bors try cancel.

[lqd]

r=me when the try build is green

[Urgau]

If the CI is effectively blocked, shouldn't we do a try-merge to avoid wasting the 1h for the try build to finish?

[Kobzol]

Ok, why not.

@bors r=lqd p=101

[bors]

📌 Commit 8fcfbcd has been approved by lqd

It is now in the queue for this repository.

[bors]

🌲 The tree is currently closed for pull requests below priority 100. This pull request will be tested once the tree is reopened.

[Kobzol]

We can parallelize them, now that try builds are in new bors :)

[bors]

⌛ Testing commit 8fcfbcd with merge de3efa7...

[rust-bors]

☀️ Try build successful (CI)
Build commit: 3f642d9 (3f642d9d77df53e9e76e5561be6f5cac39fbc32b, parent: 2886b36df4a646dd8d82fb65bf0c9d8d96c1f71a)

[bors]

☀️ Test successful - checks-actions
Approved by: lqd
Pushing de3efa7 to master...

[github-actions]

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 2886b36 (parent) -> de3efa7 (this PR)

Test differences

No test diffs found

Test dashboard

Run

cargo run --manifest-path src/ci/citool/Cargo.toml -- \
    test-dashboard de3efa79f95852c7427587f1d535bfea7c0d6779 --output-dir test-dashboard

And then open test-dashboard/index.html in your browser to see an overview of all executed tests.

Job duration changes

1. x86_64-apple-1: 7011.7s -> 10888.5s (55.3%)
2. dist-aarch64-apple: 6200.1s -> 8192.3s (32.1%)
3. pr-check-2: 2769.0s -> 2172.4s (-21.5%)
4. x86_64-rust-for-linux: 3057.3s -> 2547.3s (-16.7%)
5. i686-gnu-2: 6198.0s -> 5334.0s (-13.9%)
6. x86_64-gnu-tools: 3775.7s -> 3307.0s (-12.4%)
7. i686-gnu-nopt-1: 8376.9s -> 7355.6s (-12.2%)
8. x86_64-gnu-llvm-19-1: 3677.7s -> 3238.0s (-12.0%)
9. aarch64-msvc-1: 6388.0s -> 7123.7s (11.5%)
10. pr-check-1: 1649.0s -> 1460.8s (-11.4%)

How to interpret the job duration changes?

Job durations can vary a lot, based on the actual runner instance
that executed the job, system noise, invalidated caches, etc. The table above is provided
mostly for t-infra members, for simpler debugging of potential CI slow-downs.

[rust-timer]

Finished benchmarking commit (de3efa7): comparison URL.

Overall result: ❌ regressions - please read the text below

Our benchmarks found a performance regression caused by this PR.
This might be an actual regression, but it can also be just noise.

Next Steps:

• If the regression was expected or you think it can be justified,
  please write a comment with sufficient written justification, and add
  @rustbot label: +perf-regression-triaged to it, to mark the regression as triaged.
• If you think that you know of a way to resolve the regression, try to create
  a new PR with a fix for the regression.
• If you do not understand the regression or you think that it is just noise,
  you can ask the @rust-lang/wg-compiler-performance working group for help (members of this group
  were already notified of this PR).

@rustbot label: +perf-regression
cc @rust-lang/wg-compiler-performance

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.4%	[0.2%, 0.6%]	10
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Max RSS (memory usage)

Results (primary 2.4%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.4%	[1.2%, 3.6%]	2
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.4%	[1.2%, 3.6%]	2

Cycles

Results (primary 2.8%, secondary 3.6%)

A less reliable metric. May be of interest, but not used to determine the overall result above.

	mean	range	count
Regressions ❌ (primary)	2.8%	[2.8%, 2.8%]	1
Regressions ❌ (secondary)	3.6%	[3.6%, 3.6%]	1
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	2.8%	[2.8%, 2.8%]	1

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 465.538s -> 466.107s (0.12%)
Artifact size: 377.38 MiB -> 377.40 MiB (0.01%)

[Kobzol]

The tt-muncher results are noise:

And this is a correctness revert anyway.

@rustbot label: +perf-regression-triaged

[RalfJung]

Okay, this could have been easily fixed by just increasing the error tolerance in that one test. 🤷

@LorrensP-2158466 can you re-spin your PR with a higher tolerance for test_gamma?
Also if you could run those tests with more seeds, that'd be great.

EDIT: It seems you already did do that. We'll have to experimentally find those bounds it seems...

[LorrensP-2158466]

I'm currently running: env MIRIFLAGS=-Zmiri-many-seeds=0..10000 ./x miri --no-fail-fast std core -- f32.

This should take a while, but I'll have a pr ready today.