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_insn > => next_nonnote_insn > => next_real_insn > => next_active_insn > > I think we should keep that if possible, even during the transition period. > > Thanks, > Richard
OK, here is patch to next_real_insn to keep the ordering property intact and fix the bug. OK for checkin? Steve Ellcey sell...@imgtec.com 2013-04-29 Andrew Bennett <andrew.benn...@imgtec.com> Steve Ellcey <sell...@imgtec.com> PR target/56942 * 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 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -3248,7 +3248,8 @@ next_real_insn (rtx insn) while (insn) { insn = NEXT_INSN (insn); - if (insn == 0 || INSN_P (insn)) + if (insn == 0 || INSN_P (insn) + || JUMP_TABLE_DATA_P (insn)) /* FIXME */ break; }