Change:
<del> - // MIR for `encode` before SimplifyBranchSame + // MIR for `encode` after SimplifyBranchSame fn encode(_1: Type) -> Type { debug v => _1;                       // in scope 0 at $DIR/76803_regression.rs:+0:15: +0:16 let mut _0: Type;                    // return place in scope 0 at $DIR/76803_regression.rs:+0:27: +0:31 let mut _2: isize;                   // in scope 0 at $DIR/76803_regression.rs:+2:9: +2:16 bb0: { _2 = discriminant(_1);           // scope 0 at $DIR/76803_regression.rs:+1:11: +1:12 switchInt(move _2) -> [0: bb2, otherwise: bb1]; // scope 0 at $DIR/76803_regression.rs:+1:5: +1:12 } bb1: { _0 = move _1;                    // scope 0 at $DIR/76803_regression.rs:+3:14: +3:15 goto -> bb3;                     // scope 0 at $DIR/76803_regression.rs:+3:14: +3:15 } bb2: { Deinit(_0);                      // scope 0 at $DIR/76803_regression.rs:+2:20: +2:27 discriminant(_0) = 1;            // scope 0 at $DIR/76803_regression.rs:+2:20: +2:27 goto -> bb3;                     // scope 0 at $DIR/76803_regression.rs:+2:20: +2:27 } bb3: { return;                          // scope 0 at $DIR/76803_regression.rs:+5:2: +5:2 } } </del>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is probably
Hm, the issue is already a couple of weeks old while I was not able to reproduce this one a few days ago.
This happens since :thinking:
modify labels: +requires-nightly
Yes, this is a duplicate of . The changes from fixed the validator, so the bug is now correctly identified when incorrect transform is enabled with .
Does it still ICE if you enable optimizations?
It does, looks like it's still an ICE
This (and ) no longer ICE since , seems to be the case for any opt level cc is that intentional or is still pending?
This is only the case because the changes to MIR make that opt completely broken and just never fire under any circumstances. needs to be revised because of that change, but the plan is still for it to fix these bugs for real

Reproduction here: There's more info in the readme on that repo. Essentially, I have some code that segfaults while debug-printing an enum. The enum has one variant, followed by 11 empty variants. The repro only creates one of the empty ones, but it appears the debug routine attempts to read the string variant. It occurs in the context of some mutually recursive functions building a fairly simple datastructure by walking another. I have tried hard to minimise the repro but it could be better, but it's a bit fragile so I don't know what else I can remove. With a quick glance at the commit that bisect-rustc found, it looks like it could be related to optimising match arms, so that could be a start. Edit: for some linkage, the commit below merges , which 're-enables SimplifyArmIdentity'. searched nightlies: from nightly-2020-05-08 to nightly-2020-09-23 regressed nightly: nightly-2020-09-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x8664-apple-darwin Reproduce with: </detailsNote that the function is the one in which the debug segfaults, and it is debugging a larger structure. I have also seen it segfault when cloning just the enum, which is the String+11x one mentioned above. <details<summaryBacktrace from rust-lldb</summary<p</p</details
Can't reproduce with .
I don’t have MacOS, so I can’t test this myself easily. Here’s some tags though: modify labels: O-macos, T-compiler, E-needs-mcve. And someone might wanna add I-unsound. Edit: To clarify, I’m not seeing any segfault on Windows or Linux (both 2020-09-27). Oddly enough, I’m getting on Windows, and on Linux. And I get without on both (also with on or or in , for that matter). Is this program supposed to be deterministic?

Perhaps you could test your less minimized version on Linux or Windows if you have access to those (since you said “the segfault started to change a bit”, so maybe the original version also segfaults on e.g. Linux).
Yes, the program is deterministic. I have seen similar wrong variants as well in the original code on macOS, so I'll go out in a limb and say that's the same bug on Linux. I can run a docker image if you like but I think you've already found it. The fragility I was referring to was in terms of "add a debug statement or delete some line, the issue goes away or pops up on a different input instead". But once you have it it produces the same segfault again and again. Given the complexity of the repro I'm not surprised that platform differences including calling conventions etc would affect reproducibility. I did run in Miri and it didn't find anything amiss, and produced correct output, ie the full .
Yeah I should have made it more obvious about macOS. I can still reproduce with:
Okay, I guess if it is supposed to be deterministic, this means I can then confirm the problem for linux and windows. I’m currently trying to reduce the example further, keeping the different behavior between and debug on linux. modify labels: -O-macos
Just got a segfault on Linux with a reduced example.
SimplifyArmIdentity moves an assignment to a local before StorageLive: cc
The label might also be appropriate.
A slight modification to repro and it will segfault in release mode: I can open a PR disabling this optimization so this doesn't hit beta next week.
Marking this as P-critical based on the
We can probably turn bugs like this into ICEs by extending the MIR validator (unless another optimization interferes before this hits codegen)
Because I didn’t feel like aborting my own minimization attempt, here’s the (heavily) reduced version of OPs example that I got: Causing a segfault on linux with nightly.
Your modified example does not consistently segfault. It only does so for nightlies newer than or so. The difference between and being printed does however start from the same commit that OPs bisection identified. (Actually it does not “segfault” at all but gives me an “invalid pointer” error.)

That sounds about right to me since should have been in nightly 2020-09-26. Prior to that PR, the mis-optimization was disabled in which should have been in nightly-2020-09-19 or so. Between ~2020-09-19 and ~2020-09-26 the issue should not appear. Does your repro work on the playground? When I try it with the nightly available, it works correctly.
Opened with an implementation of this. It does indeed catch this miscompilation.
It doesn’t seem to work in the playground. Even the (mostly) untouched original code that OP provided . (I.e. it correctly displays .) To demonstrate some online reproduction: (exit code 139).
I can reproduce with based on one of the MCVEs: stderr stdout
Perhaps change the title of the issue to "... in release mode"?
Is this still open so that the underlying issue is fixed? (The PR to temporarily disable the optimization was merged.)
We should leave this issue open to track fixing the optimization but we can remove some of the tags. Once a nightly goes out with the fix, we should also confirm it's no longer repros on the nightly channel. (I was going to wait for that confirmation before changing any labels)
Both repros work correctly on the latest nightly (2020-10-02), so I'm adjusting the tags accordingly. Thanks for reporting this issue!
Did you mean to remove ?
Yeah