On Wed, Feb 17, 2016 at 06:31:45AM -0600, Segher Boessenkool wrote: > > Corresponding content of "op" which causes the ICE: > > gdb) p debug_rtx (op) > > (gtu:SI (reg:CC 166) ---------------------- (operator and mode doesn't > > match) > > (const_int 0 [0])) > > That is invalid RTL for this target (should be CCUNS). Invalid RTL > should not be passed to recog.
Really?? combine does that all the time, when it asks "is this instruction valid"! > > (gdb) p debug_rtx (other_insn) > > (insn 11 10 16 2 (set (reg:SI 165 [ D.2339+-3 ]) > > (if_then_else:SI (ne (reg:CC 166) > > (const_int 0 [0])) > > (reg:SI 168) > > (reg:SI 167))) test.c:7 317 {isel_unsigned_si} > > (expr_list:REG_DEAD (reg:SI 168) > > (expr_list:REG_DEAD (reg:SI 167) > > (expr_list:REG_DEAD (reg:CC 166) > > (expr_list:REG_EQUAL (gtu:SI (reg:CC 166) > > (const_int 0 [0])) > > (nil)))))) > > The REG_EQUAL there is bad already. Where does that come from? Rohit explain that quite well already, I thought. It's there due to combine transforming a GTU to NE in another insn, which means the reg mode changes to CCmode via rs6000.h:SELECT_CC_MODE. You might argue that combine shouldn't create such a note, but whether the note is valid or not depends on the target, doesn't it? And the usual way for combine to check validity of rtl is to form up an instruction and pass that to recog. Which is exactly what happens later when combine tries to use the note and runs into the rs6000 backend assert. It seems quite plain to me that this is primarily an rs6000 backend problem, solved by the blindingly obvious patch I posted. Whether you want to do something in combine as well is a secondary problem. The rs6000 backend shouldn't assert on this rtl. -- Alan Modra Australia Development Lab, IBM