Change:
Discovered in I don't have reduced code, but the testsuite fails on when compiled in mode, specifically on this line: It fails when compiled from x8664 host: or with a native i686 host toolchain: I expected to see this happen: the test should pass Instead, this happened: FAILED The left is wrong, and the right is correct. They both come from the same generated sieve, so that part of the code appears to have worked correctly. That leaves the difference between the loop and the , and while does implement both and , the differences are small. The same test passes on i686 in debug mode, as well as x8664 in debug or release. It most recently worked on: stable Rust 1.58.1 Both beta and nightly are failing the same way. modify labels: +regression-from-stable-to-beta -regression-untriaged
I just tried under qemu to see if the bug is a 32-bit thing, but that passes fine.
It passes on i686 release with .
The relevant difference with the NewPM seems to be that the next() method gets inlined now.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
Just tested this with the toolchain and it still fails, so this issue is not fixed in LLVM 14.
does have an attribute, and if I remove that, the test passes. But even is not enough to make oldPM fail. Also, forcing newPM with 1.58.1 still passes as well! Between stable and beta, the most significant change looks like the patch to disable deferred inlining -- and the test does pass on beta and nightly with . (That doesn't mean the inlining decision is wrong -- it's probably just creating circumstances that are buggy in another pass.)
and I just found a slight variant that shows a similar failure on x86_64....
We're discussing in this . After discovering the variant where x86_64 fails, we found that it also failed on stable back to 1.55, but passed on 1.54. Bisecting between those took me to , a simple addition, which I take to mean it just perturbed the code enough to expose a pre-existing codegen bug. So, I'm removing the regression label, and we can treat it like any ongoing bug.
FYI I took the test from the primal crate and reduced it down to a single (large!) file: I suspect this is still too absurdly large to turn into LLVM bitcode to file a bug with LLVM. But, just as i write this, I realize it might suffice as input for the bitcode automatic reduction tools that LLVM distributes. Looking in that next.
This is flagged as P-critical, but I do not believe it is a 1.59.0 release blocker. (And I think the release team .) The investigation, covered in , determined this bug is visible as far back as 1.55.0. So: should it be downgraded to P-high? I think the nature of the bug (outright miscompilation) warrants us covering it on a weekly basis in T-compiler meeting, at least for now. So I won't downgrade it yet; we can let the team decide if it should be downgraded during regular triage meeting.
Upstream issue: Not a great reduction, but my attempts to construct a minimal MIR test failed.
The does work for me, thanks!
Priority label has been mentioned during T-compiler weekly meeting . This will be reviewed in a follow-up meeting.

Discussion:
// The new pass manager is enabled by default for LLVM >= 13. // This matches Clang, which also enables it since Clang 13. <del> // FIXME: There are some perf issues with the new pass manager // when targeting s390x, so it is temporarily disabled for that // arch, see https://github.com/rust-lang/rust/issues/89609 user_opt.unwrap_or_else(|| target_arch != "s390x" && llvm_util::get_version() >= (13, 0, 0)) </del> <ins> // There are some perf issues with the new pass manager when targeting // s390x with LLVM 13, so enable the new pass manager only with LLVM 14. // See https://github.com/rust-lang/rust/issues/89609. let min_version = if target_arch == "s390x" { 14 } else { 13 }; user_opt.unwrap_or_else(|| llvm_util::get_version() >= (min_version, 0, 0)) </ins> }

<del> Subproject commit e29ac13bc97e26f886c3bfe72f9135e994c3cd0a </del> <ins> Subproject commit c8eccf626fb5bb851b2ade93af8851ca1523807f </ins>

// run-pass <del> // ignore-wasm32-bare FIXME(#93923) llvm miscompilation </del> use std::collections::HashMap; use std::path::Path;