------- Comment #7 from namolaru at il dot ibm dot com 2007-06-25 11:17 ------- (In reply to comment #5) > This bug should be assigned to Mircea Namolaru <[EMAIL PROTECTED]>. I have > sent him mail asking that he get a proper bugzilla id. > ================================== > The underlying problem is that see.c:2732 uses copy_rtx to make a copy > of an insn and then hacks on it with validate_change (and it's close > relatives). This is not the approved way to copy an insn. > The copy_rtx function has two problems with df: > 1) The copy has a basic_block, even though it is not > in the insn stream, > 2) The copy has the same insn_uid as the old insn. This is not legal > and confuses df which keeps side info indexed by the insn_uid. > There are several proper ways to make a copy of an insn: > 1) call make_insn_raw (copy_rtx (PATTERN (ref))). > 2) However, according to Ian Taylor, a middle end maintainer, the > better thing to do would be to copy the pattern of the insn, not the > insn itself and then hack on that. > However, you then make a move insn and hack the modified copy so that > it is right next to the move. What you should do insert the copy > before the new move using one of the calls in emit_rtl such as > add_insn_before. No one is supposed to hack the next and prev insn > themselves. > The rest of the pass appears to be df ready. Of course until it is > tested it most likely does not work. And so adding some regression > tests would be good.
Working on this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32300