https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231
--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 12 Apr 2022, ebotcazou at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105231 > > --- Comment #13 from Eric Botcazou <ebotcazou at gcc dot gnu.org> --- > > Oh, and checking for REG_EQUAL notes on i2/i3 doesn't work since they do not > > exist there. Likewise REG_EQUAL notes can be simply dropped which would > > make the IL "invalid" so I think what purge_dead_edges does is premature? > > Everything is consistent until combine messes things up, so I'd rather find a > fix/kludge in combine if possible. Penalizing everyone because of an > artificial testcase exercising a nonsensical set of options is IMO not the way > to go. So my original patch still works - since combine doesn't split the block, transfering EH edges, when it moves the note to i2 it should simply never do that but instead drop it on the floor. Which of course is a kludge and possibly wrong-code. Alternatively we could mark as non-trapping (insn 36 35 37 (set (reg:XF 95) (float_extend:XF (reg:SF 96))) "t.c":6:3 -1 (expr_list:REG_EH_REGION (const_int 1 [0x1]) (expr_list:REG_EQUAL (const_double:XF 1.8446744073709551616e+19 [0x0.8p+65]) (nil)))) at the point we remove the REG_EH_REGION note because of the REG_EQUAL note? Because we know it won't trap.
