This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee



------- 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 <namolaru@il.ibm.com>.  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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]