https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93444
Bug ID: 93444 Summary: [8/9/10 Regression] unswitching introduces unconditional use of uninitialized variable Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: amonakov at gcc dot gnu.org CC: ch3root at openwall dot com Target Milestone: --- Splitting out bug 93301 comments 6 and 7. __attribute__((noipa)) static int opaque(int i) { return i; } int main() { short x = opaque(1); short y; opaque(x - 1); while (opaque(1)) { __builtin_printf("x = %d; x - 1 = %d\n", x, opaque(1) ? x - 1 : 5); if (opaque(1)) break; if (x - 1 == y) opaque(y); } } Prints "x = 1; x - 1 = 5" at -O3. Loop unswitching introduces an unconditional use of an uninitialized variable which otherwise is conditional and never executed. The testcase hits a problematic early-out in is_maybe_undefined: /* Uses in stmts always executed when the region header executes are fine. */ if (dominated_by_p (CDI_DOMINATORS, loop->header, gimple_bb (def))) continue; the code does not match the comment, checking postdominators might be correct, but not dominators. This was introduced by r245057 for PR71691.