Change:
<del> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </del> <ins> Subproject commit 22897bce7bfedc9cd3953a33419b346936263500 </ins>

Discussion:
The reproduction is fuzzer-generated custom MIR then (somewhat) minimised. I couldn't rewrite it into surface Rust as there are back edges to non-dominating basic blocks (they can't be turned into surface Rust loops). It's possible that rustc considers such control flow invalid, though this is likely an LLVM miscompilation and such control flow is valid at LLVM IR level. Miri also does not complain. The actual execution flow has no loops, all statements are executed only once. Indented BBs are not taken, but still required for the reproduction. In Miri, the program is UB-free under both Stacked Borrows and Tree Borrows. The correct result is 1 at , it prints 255, which is clearly wrong as the value came from a bool to int cast. prevents the miscompilation, also does. Implying either the generated IR has UB or this is a bug in LLVM Only reproducible on x8664 Linux, not Apple Silicon macOS (This is still reproducible even with applied, so it's a separate bug) I tried to get a standalone LLVM IR file using approach in by having in helper C code, but I couldn't reproduce the misoptimisation with since the pre-populated passes from rustc are required for the reproduction, which does not replicate (or not in the same order) cc
Cleaned up input IR: After : After llc: So this looks like a backend bug.
Yes it's an x86 backend bug
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Is this a regression (from-stable-to-stable?)
Since the Rust reproduction is in custom MIR, it's hard to test using older nightlies as a lot of expressions are only parsable recently. But on the LLVM side the bug existed since LLVM 9: , which Rust started using from 1.38.0

Apologies for the not-very-readable reproduction. It was generated by a fuzzer and this is the best I can minimise it to. The program has no UB under , and Miri prints 22, this is also the result with Very strangely, if you drop to 0 or 1, the result becomes 11 which is wrong. Reproducible on both Apple Silicon macOS and x8664 Linux cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Executing the program trough reveals that under Stacked Borrows there is UB:
It does, and since the UB involves and which carry the wrong and right results (11 and 22), the miscompilation is likely due to an assumption that was valid under SB but not under TB. Though this bug probably isn't in mir-opt as a low gives the wrong result. It could be in IR gen or LLVM itself
(defensively labeled this as unsound because that seems more likely than not)
is relevant:
Here's the diff that ConstProp produces. Does this look relevant? Relevant stuff is buried down in the pile of scopes ugh. The relevant diff smells like
This is the relevant diff, but ConstProp is correct here: ( in the original source) is not aliased by anything, 6 can be propagated. Indeed the result with ConstProp is right and without_ is wrong, it actually mitigated a bug further down the pipeline
Slightly edited to make the executed control flow simpler: no loop is taken more than once except for , which executes one line and then returns on the second iteration. <details<summarySee</summary</details
I put this together to look through what LLVM is doing with and without ConstProp enabled:
Regression in nightly-2022-08-13 which was when we did the llvm 15 upgrade
WG-prioritization assigning priority (). Provisionally assigning a P-high priority, will be discussed in the next compiler meeting. label -I-prioritize +P-high +I-compiler-nominated
Note that the compiler is not intended to exploit SB yet so this is still a bug (either in rustc, or in TB failing to represent some UB that we really need).

Since this only happens on low optimization levels, and based on the regression range, looks like an LLVM issue masked by rustc ConstProp? Cc
This version has no UB under Stacked Borrows but still triggers the misoptimisation
I've started to minimize it further: more updates will come later repo:
I don't have a compiled LLVM lying around, could you run your reduction with an LLVM built with ASan? My fuzzer was also running into this segfault , and on this repro when I tried , I would get segfaults if I put the index too low (i.e. disabling too many optimisations!). I have a suspicion that they are related
I don't have an LLVM built with ASan around either right now, but I do have alive2 yelling at me when I feed in a reduced version of this test case. I'll create an issue soon I guess. But I can look into ASan as well.
I checked with ASan and it all looked fine. As backlinked already, I also created an LLVM issue: llvm/llvm-project
The bug has been fixed in assign

: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this doesn't seem to be rustc's fault: , so an LLVM issue would probably also be good. Interestingly, it compiles just fine on aarch64, and it also compiles on x86 when you change the third argument of the LLVM intrinsic from 0 (icache) to 1 (dcache).
I've submitted it to LLVM. Much nicer now that they use GitHub instead of bugzilla.
assign Assigning it for closing the issue on the next LLVM upgrade that includes the patch.
Seems similar to which also causes llvm errors by default.