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.

Reply via email to