1*cee313d2SEric Christopher; RUN: opt < %s -reassociate -disable-output 2*cee313d2SEric Christopher 3*cee313d2SEric Christopher; It has been detected that dead loops like the one in this test case can be 4*cee313d2SEric Christopher; created by -jump-threading (it was detected by a csmith generated program). 5*cee313d2SEric Christopher; 6*cee313d2SEric Christopher; According to -verify this is valid input (even if it could be discussed if 7*cee313d2SEric Christopher; the dead loop really satisfies SSA form). 8*cee313d2SEric Christopher; 9*cee313d2SEric Christopher; The problem found was that the -reassociate pass ends up in an infinite loop 10*cee313d2SEric Christopher; when analysing the 'deadloop1' basic block. See "Bugzilla - Bug 30818". 11*cee313d2SEric Christopherdefine void @deadloop1() { 12*cee313d2SEric Christopher br label %endlabel 13*cee313d2SEric Christopher 14*cee313d2SEric Christopherdeadloop1: 15*cee313d2SEric Christopher %1 = xor i32 %2, 7 16*cee313d2SEric Christopher %2 = xor i32 %1, 8 17*cee313d2SEric Christopher br label %deadloop1 18*cee313d2SEric Christopher 19*cee313d2SEric Christopherendlabel: 20*cee313d2SEric Christopher ret void 21*cee313d2SEric Christopher} 22*cee313d2SEric Christopher 23*cee313d2SEric Christopher 24*cee313d2SEric Christopher; Another example showing that dead code could result in infinite loops in 25*cee313d2SEric Christopher; reassociate pass. See "Bugzilla - Bug 30818". 26*cee313d2SEric Christopherdefine void @deadloop2() { 27*cee313d2SEric Christopher br label %endlabel 28*cee313d2SEric Christopher 29*cee313d2SEric Christopherdeadloop2: 30*cee313d2SEric Christopher %1 = and i32 %2, 7 31*cee313d2SEric Christopher %2 = and i32 %3, 8 32*cee313d2SEric Christopher %3 = and i32 %1, 6 33*cee313d2SEric Christopher br label %deadloop2 34*cee313d2SEric Christopher 35*cee313d2SEric Christopherendlabel: 36*cee313d2SEric Christopher ret void 37*cee313d2SEric Christopher} 38