https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90275
--- Comment #20 from Jeffrey A. Law <law at redhat dot com> ---
90275, the gift that keeps giving. While the failure is similar, this feels
slightly different.
In this case we've got:
(insn 60 54 61 4 (parallel [
(set (reg:CC 100 cc)
(compare:CC (reg:SI 252 [ _5 ])
(const_int 0 [0])))
(set (reg:SI 256 [ _5 ])
(reg:SI 252 [ _5 ]))
]) "j.c":8:15 248 {*movsi_compare0}
(expr_list:REG_UNUSED (reg:SI 256 [ _5 ])
(nil)))
That gets (reg 252) into the tables. We invalidate it when we hit this insn in
the same block:
(insn 65 64 66 4 (parallel [
(set (reg:SI 252 [ _5 ])
(mult:SI (reg:SI 252 [ _5 ])
(reg:SI 252 [ _5 ])))
(set (reg:SI 253 [ _5+4 ])
(truncate:SI (lshiftrt:DI (mult:DI (zero_extend:DI (reg:SI 252
[ _5 ]))
(zero_extend:DI (reg:SI 252 [ _5 ])))
(const_int 32 [0x20]))))
]) "j.c":8:9 68 {umull}
(nil))
We then trigger the assert when handling this insn from the block:
(insn 174 173 175 4 (set (reg:SI 0 r0)
(reg:SI 252 [ _5 ])) "j.c":8:20 241 {*arm_movsi_insn}
(nil))
At the point where we simplify insn 60 into the form above, we don't know the
destination of the second set is unused. That's not exposed until cse2 and I'm
not terribly inclined to do the DF analysis earlier and try to split that insn.
I'm not sure of the best fix here, nor is it clear why we're having so much
trouble with this code. The real guts of this code hasn't changed materially
in decades.
