This is the mail archive of the
mailing list for the GCC project.
Re: [patch, mips] Fix for PR target/56942
- From: Steve Ellcey <sellcey at imgtec dot com>
- To: Richard Sandiford <rdsandiford at googlemail dot com>
- Cc: <gcc-patches at gcc dot gnu dot org>, <andrew dot bennett at imgtec dot com>, <stevenb dot gcc at gmail dot com>
- Date: Mon, 29 Apr 2013 13:13:33 -0700
- Subject: Re: [patch, mips] Fix for PR target/56942
- References: <2c243f55-9b58-4e4a-86cf-9dd5be8ea183 at BAMAIL02 dot ba dot imgtec dot org> <87sj2gifze dot fsf at talisman dot default> <1367016105 dot 1650 dot 43 dot camel at ubuntu-sellcey> <87ehdwiezi dot fsf at talisman dot default>
On Sat, 2013-04-27 at 08:56 +0100, Richard Sandiford wrote:
> >> But using next_real_insn was at least as correct (IMO, more correct)
> >> as next_active_insn before r197266. It seems counterintuitive that
> >> something can be "active" but not "real".
> >> Richard
> > So should we put the active_insn_p hack/FIXME into real_next_insn? That
> > doesn't seem like much of a win but it would probably fix the problem.
> Yeah, I think so. If "=>" mean "accepts more than", then there used
> to be a nice total order:
> => next_nonnote_insn
> => next_real_insn
> => next_active_insn
> I think we should keep that if possible, even during the transition period.
OK, here is patch to next_real_insn to keep the ordering property intact
and fix the bug. OK for checkin?
2013-04-29 Andrew Bennett <firstname.lastname@example.org>
Steve Ellcey <email@example.com>
* emit-rtl.c (next_real_insn): Accept jump table data
as 'real' (like next_active_insn does).
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index 538b1ec..9de3f1e 100644
@@ -3248,7 +3248,8 @@ next_real_insn (rtx insn)
insn = NEXT_INSN (insn);
- if (insn == 0 || INSN_P (insn))
+ if (insn == 0 || INSN_P (insn)
+ || JUMP_TABLE_DATA_P (insn)) /* FIXME */