Change:
<del> Subproject commit 5f958e150d377e608d2f1f208b86110218d5da3c </del> <ins> Subproject commit 62a1ddde22c267249eda72184520a21ad2052f0b </ins>

Discussion:
I tried this code (thanks to for the minified version): I expected the code to print , the length of the slice. Instead, a random value is printed. It most recently worked on: : : <!-- Did the compiler crash? If so, please provide a backtrace. -- modify labels: +regression-from-nightly-to-nightly -regression-untriaged
Are you able to share a code snippet that reproduces your bug, even a long example is fine for now?
Very likely caused by LLVM upgrade.
I'm having lunch now, but I'll see what I can do afterwards :)
So far, my only progress is that works whilst the following does not: Again, adding a inside the loop makes the second example work. I'm still trying to reduce this problem to an example which can be reproduced without including code from my project.
Ok, I finally was able to reduce this bug to its bones - here is the code (it turned out to be quite different than what I had originally expected): You can see that on the current nightly, this snippet prints a random value: It should, as demonstrated on the release branch, print , the length of the slice : My best guess is that in debug mode (this bug does not occur in release), we are actually trying to read the length of our slice . However, some change to codegen may have optimised out storing that length, so that we are reading garbage from the stack.
Slightly smaller:
Hmm, this also happens in debug mode for me (both with the larger and smaller example).
It doesn't work in release mode. It only works in debug mode
This requires : -
This is likely the same issue as .
Assigning and removing .

On nightly 2021-03-05, with , I am experiencing undefined behaviour which seems to be based around . I ran this code: I expected to see the following output: I get the above output on stable 1.50.0, or on the same nightly version if I remove at least one of the three listed above. With all three flags present, on nightly 2021-03-05 I see the following output: The exact bytes count varies, so this looks like UB to me. : </p</details
Regressed since rustc 1.52.0-nightly ( 2021-03-04). At a glance, might be related.
Compiling with nightly-2021-03-05 on : I am not able to reproduce the crash, though the result is still incorrect: console $ RUSTFLAGS="-Ccodegen-units=1 -Cinline-threshold=0 -Clink-dead-code" cargo +nightly run Compiling issue82833 v0.1.0 (/Users/tous/Documents/Dev/rustcissues/issue82833) Finished dev [unoptimized + debuginfo] target(s) in 46.25s Running [] ch = '' [] string = "u{0}u{0}u{0}u{0}"
is indeed the culprit:
ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Through an experiment wherein I link a produced from to a test program such as this: I verified that this issue is caused by something in the function itself, rather than the test glue in . Sadly, this is pretty hard to actually root cause because any attempts to remove and out of equation end up fixing this :(
I had to additionally use to reproduce the issue. The length of slice returned from is passed incorrectly to ; it is read from a stack slot that is uninitialized.
Assigning .
To illustrate what is saying: you can see that the and are stashed in some place on the stack, and the arguments are filled/reloaded from another area. This won't happen when we compile the LLVM IR with from LLVM head.

I haven't tried with an LLVM build from our fork, but I'm not at all confident it'll help in reducing the problem.
Relevant IR: Under this gives the suspicious stack manipulations. And if you drop the there is an assertion failure:
Reducing the assertion failure gives: Running with we get: The kill flag on the MOV64mr is not correct. Possibly FastISel related.
Upstream report: Fixing this does seem to fix the original case as well.
also assigning just to doubly-ensure backport (from LLVM upstream to Rust's LLVM fork) for fixing this P-critical bug happens.