Closed
Description
#[inline]
pub fn imm8(x: u32) -> u32 {
let mut out = 0u32;
out |= (x >> 0) & 0xff;
out
}
#[inline(never)]
pub fn inner(fields: u32) -> i64 {
imm8(fields).rotate_right(((fields >> 8) & 0xf) << 1) as i32 as i64
}
fn main() {
let val = inner(0xe32cf20f);
println!("{val:#x}");
}
This code normally prints 0xfffffffff0000000
but when compiled with O -C debug-assertions=on -Zmir-opt-level=2
it produces 0x0
instead. This was noticed because MIR optimization is enabled by default on the current nightly.
This is the LLVM IR for the inner
function with -C no-prepopulate-passes
. Notice how the inputs to llvm.fshr.i32
(used by rotate_right
) are 0
, which is incorrect.
define i64 @_ZN4test5inner17hd60ec7d5b1d44c39E(i32 %fields) unnamed_addr #0 {
start:
%0 = alloca i32, align 4
%_13.0 = lshr i32 %fields, 0
br label %bb3
bb3: ; preds = %start
%_10.0 = lshr i32 %fields, 8
br label %bb1
bb1: ; preds = %bb3
%_7 = and i32 %_10.0, 15
%_11.0 = shl i32 %_7, 1
br label %bb2
bb2: ; preds = %bb1
call void @llvm.lifetime.start.p0(i64 4, ptr %0)
%1 = call i32 @llvm.fshr.i32(i32 0, i32 0, i32 %_11.0)
store i32 %1, ptr %0, align 4
%_3 = load i32, ptr %0, align 4
call void @llvm.lifetime.end.p0(i64 4, ptr %0)
br label %bb4
bb4: ; preds = %bb2
%2 = sext i32 %_3 to i64
ret i64 %2
}
Activity
[-]Incorrect code generated with -Z mir-opt-level=2[/-][+]Incorrect code generated by MIR optimization on nightly[/+]matthiaskrgr commentedon Sep 18, 2022
@rustbot prioritize
steffahn commentedon Sep 18, 2022
@rustbot label regression-from-stable-to-nightly, I-unsound, A-mir-opt, T-compiler
JakobDegen commentedon Sep 19, 2022
Can someone execute the snippet with
-Zdump-mir=all
and upload the resultingmir-dump
directory somewhere? That should allow me to debug from my phone 😆Amanieu commentedon Sep 19, 2022
https://gist.github.com/Amanieu/183f034864c71a580b2f3347abc5b83d
steffahn commentedon Sep 19, 2022
I’ve made a gist originally, too, but it looks like you can’t see all the files there. (Afaict only 300 of the 401 files show up.)
Here’s a repo https://github.com/steffahn/rust_issue_101973
Edit: One downside of a repo (compared to a gist) is that I might want to get rid of it eventually; AFAIK, this shouldn’t be needed for too long anyway though.
tmiasko commentedon Sep 19, 2022
With an assertion instead of println:
Individual builds from #101152 (comment), point to #100239 cc @RalfJung
RalfJung commentedon Sep 19, 2022
Ouch. That probably means the unsoundness was already possible before my PR (as explained there, the check it removes was ineffective), but is easier to trigger now.
Cc @oli-obk @rust-lang/wg-mir-opt something is wrong in ConstProp handling of shifts and/or casts and/or bit-ops.
Is there a reproducer that does not need shifts and casts and a bitop? That would make the issue easier to track down.
RalfJung commentedon Sep 19, 2022
FWIW it prints 0xfffffffff0000000 in Miri so the interpreter is probably fine, and it's probably a problem with the ConstProp pass itself.
Amanieu commentedon Sep 19, 2022
The original code was much more complex. I minimized it as much as I could, but at this point even removing a useless
>> 0
will cause the bug to no longer trigger.RalfJung commentedon Sep 19, 2022
Yeah I quite appreciate that it does fit in a few lines now. :)
RalfJung commentedon Sep 19, 2022
The
-Zmir-opt-level=2
is not needed, but indeed the bug needs-O -C debug-assertions=on
to trigger. And inlining. Very strange.ConstProp code is super hard to read and full of subtle (usually barely documented) invariants, so... this could be an interesting one to track down.
RalfJung commentedon Sep 20, 2022
The inlined code looks fine, but it has the basic blocks in a strange order, which might explain why the ConstProp bug only occurs if inlining happens first.
The code just before ConstProp has this
One possible explanation would be if ConstProp iterated the basic blocks in order, then by the time it reaches
rotate_right
, the last assignment to_4
it saw is_4 = const 0_u32
in bb0. There is another assignment to_4
in bb3, which is executed before bb2, but maybe somehow my change made it so that this is not taken into account properly any more.RalfJung commentedon Sep 20, 2022
Turns out the actual problem was an early return that I added which skipped more code than it should have -- fixed by #102045.
apiraino commentedon Sep 20, 2022
WG-prioritization assigning priority (Zulip discussion).
@rustbot label -I-prioritize +P-critical
Rollup merge of rust-lang#102045 - RalfJung:const-prop-regression-fix…
Rollup merge of rust-lang#102045 - RalfJung:const-prop-regression-fix…