InstCombine
can incorrectly deinitialize locals that are later used
#72797
Labels
A-mir-opt
Area: MIR optimizations
C-bug
Category: This is a bug.
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Since #72093 InstCombine can now introduce
Operand::Move
where there was none before, without checking that the value is in fact not used afterwards. This may cause a value to be marked as uninitialized by theMaybeInitializedLocals
dataflow, but still be used in that uninitialized state.If InstCombine ran before the generator transform this would be acutely unsound and could probably be exploited directly, but other than that transform I don't think we rely on this property yet.
This impacts #72632, which does run after InstCombine and relies on the
MaybeInitializedLocals
dataflow.I've observed this on
BinaryHeap::peek_mut
, where it produces this diff:The second use of
_1
occurs despite the first move deinitializing the local.cc @rust-lang/wg-mir-opt
The text was updated successfully, but these errors were encountered: