Change:
<ins> // This is a regression test for issue rust-lang/rust#69841, which exposed an // LLVM bug which needed a fix to be backported. // run-pass fn main() { let buffer = [49u8, 10]; let mut a : u64 = 0; 'read: loop { for c in &buffer { match c { 48..=57 => { a*= 10; a+= *c as u64 - 48; } 10 => { break 'read; } _ => { unsafe { std::hint::unreachable_unchecked() }; } } } } if a == 1 { println!("What did you expect?"); } else { panic!("this should be unreachable."); } } </ins>

Discussion:
The following code tries to parse a decimal integer followed by a newline. For some reason the compiler assumes that the parsed number will never be one. opt-level has to be 2, 3, s or z I expected to see this happen: When running the program it prints "What did you expect?" Instead, this happened: The program doesn't print anything, just exits : On the issue seems to go back to version 1.38
Just out of curiosity, I bisected to . Probably not helpful, but I see a note about changes to unreachability in jump tables in the .
cc
Looks like the condition gets removed by instcombine: (Might be caused by a prior change though.)
I found that the same IR optimizes correctly with LLVM master. I'm currently bisecting...
Based on the structure of the IR, my first guess would be the InstSimplify part of
You're right, it's bad up to () and correct with .
Also, it's fine with LLVM 8, consistent with bisection, so this is just a regression in LLVM 9. edit: I bisected the regression specifically to
Could you post dumps from both before and after instcombine ?
ping icebreakers-llvm Namely, we have these LLVM-specific work items: [x] The comment thread above indicates that this is fixed upstream [x] Is there an attached bug for the fix? [x] can we backport a narrow fix? [ ] and/or push the upgrade through to the newer version of 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://rust- cc
If this proves difficult, another option is to revert the commit that introduced it.
For backporting, it should be fine to take the part of the patch up to (and including) , and drop the part after it. The part below it is a new feature that should not be backported.
pre-triage: nominating for discussion on next meeting.
I'm volunteering to mentor someone through resolving this bug.
Doesn't this bug only need a submodule update?

It needs someone to do the LLVM backport, as suggested above, in a PR to rust-lang/llvm-project. Then yes, it's a submodule update here, with a regression test if possible.
, when you : are the "before"/"after" referring to portions of that diff? Or to commits in a series? (in other words, what is the implicit sequence of things referenced there?) My current inference is that the "part after it" that you are saying we need to drop the changes that are in , and keep all the changes that are about the "context instruction to the 'edge' that flows into the phi." but I am not 100% sure about that inference.
Yup, that's right. The changes to are a new optimization that shouldn't be backported. The rest are fixes for issues that this new optimization exposed, but which are also reproducible (as this issue shows) without it.
Okay, so here are my mentoring notes: Adapt the code on this issue into a regression test. Make sure you have a test that fails. (Note that the issue as written is not a failing test; it just has differing stdout output, which is not really usually how we write our regression tests on this project. E.g. a panic! in the block would be more in line with how we usually do things.)Grab the diff from I don't know if there's an easy way to coax github into supplying the raw diff for a given commit; but you can go back to the LLVM reviews site for one: just the pieces mentioned above, that are about changing the context instruction to the "edge" that flows into the phi, and apply those to the submodule in .Ensure that the aforementioned change fixes the test you made in step 1.Optional, and probably too much effort to be worthwhile: Figure out how to make a test specific to LLVM project. (One might do this by first taking the original test from step 1 and reducing the LLVM IR associated with it down to something that doesn't rely on anything related to Rust.)Land the LLVM changes on Rust's llvm-project fork.Update Rust's submodule dependency to include the fix on Rust's LLVM fork.

You can append to the commit url, like so:
(I decided to go ahead and take care of it, further mentoring/publicizing would probably be just as much work as the PR I've posted at )
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
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