------- 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

Reply via email to