Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub fn pr32379(mut data: u64, f1: bool, f2: bool) -> u64 { if f1 { data &= !2; } if f2 { data |= 2; } data } </ins>

Discussion:
When running the program at: on my Chromebook (an Asus C201p) with the latest nightly compiler, I get the following error (RUST_BACKTRACE=1): This doesn't occur on the latest stable compiler, and started sometime around March 12. This doesn't happen on my AMD 64bit desktop, nor on playground. Both debug and release builds are affected. Code: (note the extra scopes don't affect the behaviour.)
This may be related to . It would appear like dropping of values is broken in the nightly and beta toolchain: This works: but this fails: This seem a rather new issue, in nightly-2017-03-01 it still worked. (May also work in few of the newer versions, haven't had time to try all of them.)
Tried a few more nightly snapshots nightly-2017-03-04 is the first affected version, nightly-2017-03-03 works flawlessly.
Where can you find the nightly snapshots? I tried downloading them with , but it said older ones couldn't be found.
This worked for me:
looks like the main diff. between the 2 versions. Self-assigning.
I can't reproduce this on (03-11) on debian qemu. Could you upload an affected output?
The first example is optimized out completely on my machine (using ), so it is unlikely to have issues.
I get BorrowMutError on my machine too. Here's the ASM output: . Compiled using (2017-03-18).
Did you run that on an armv7 machine, or on a x86(64) machine? It seems something really weird is happening in the compiler. I'm working with a simpler example (see end of this post). A compiler on x8664 produces a MIR representation that seems to make sense (dropping the option, and then the inner type). However with an armv7 compiler, it doesn't drop the option, but tries to drop the T (while inside the option). I'm not familiar with what the correct representation is, but that is the big difference I see on armv7. And just to be clear, I need to use a native compiler to see that difference. Cross-compiling the source file does not produce the difference.

If it would help, I'll try to post the different outputs from MIR comparing before/after March 4 between x86_64 and armv7. I also don't think it's an issue in the MIR optimization passes, as when I dump the MIR using -Z dump-mir=all, that difference is always present. I'm doing all my testing right now with debug builds, but my initial testing before reporting the bug happened with both debug and release. New example:
I am using an ARM compiler (rustc 1.17.0-nightly ( 2017-03-03) aka the Mar 4 nightly) in an x86_64 machine using qemu, which seems not to reproduce the bug. I don't have an ARM machine handy right now,
Ah. The problem was that I was using the nightlies instead of the nightlies. Only the armv7 nightlies are broken/miscompiled. Correct "at-typeck" MIR looks like this: Incorrect "at-typeck" MIR looks like this:
Looking at direct builder output: BAD: GOOD:
debugging. It seems that after , type contents is miscompiled somehow.
I've tried bisecting the problematic change and came up with the same commit causing the issue, but at the same time reverting the change on top of master () didn't fix it. I'll keep trying poke things here.
Reverting things did fix things for me. This is however, a miscompile, so problems are to be expected.
Did you revert it on top of master, or on top of the nightly build from March 4th?
On top of
Looks like an LLVM bug, unless we have some "hidden" UB somewhere: For some reason, this IR: Lowers the last call/or/select as And a is not a very good . Oops.
Could you post the entire file, or give me steps to generate/investigate it locally? I'm new to playing with rustc's codebase and would like to take a deeper look/follow along at home.
This looks like an LLVM bug, not a rustc bug.
That's fine, I'm just trying to learn more about the stack. If you have a reference for how you got that, I'm happy to read that as well.

Minified LLVM bug - will report to LLVM after seeing the status on 4.0:
Reported as
triage: P-high