This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
- From: "namolaru at il dot ibm dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 Jun 2007 11:17:07 -0000
- Subject: [Bug rtl-optimization/32300] [4.3 Regression] ICE with -O2 -fsee
- References: <bug-32300-8535@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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