Code change:
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

Related discussion:
text: <del> Subproject commit 533d3f338b804d54e5d0ac4fba6276af23002d9c </del> <ins> Subproject commit 22897bce7bfedc9cd3953a33419b346936263500 </ins>