On Wed, 2013-04-24 at 07:45 +0100, Richard Sandiford wrote:
> "Steve Ellcey " <sell...@imgtec.com> writes:
> > 2013-04-19 Andrew Bennett <andrew.benn...@imgtec.com>
> > Steve Ellcey <sell...@imgtec.com>
> >
> > PR target/56942
> > * config/mips/mips.md (casesi_internal_mips16_<mode>): Use
> > next_active_insn instead of next_real_insn.
>
> Hmm, I don't really like this. Steven said from ARM in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56809:
>
> -----------------------------------------------------------------------
> Target bug, this is wrong:
>
> rtx diff_vec = PATTERN (next_real_insn (operands[2]));
>
> A jump_table_data is not a real insn. Before my patch this worked
> by accident because the jump table would hide in a JUMP_INSN and
> next_real_insn returned any JUMP_P insn.
>
> Use next_active_insn instead.
> -----------------------------------------------------------------------
>
> 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.
Steve Ellcey
sell...@imgtec.com
>From emit-rtl.c:
/* Find the next insn after INSN that really does something. This routine
does not look inside SEQUENCEs. After reload this also skips over
standalone USE and CLOBBER insn. */
int
active_insn_p (const_rtx insn)
{
return (CALL_P (insn) || JUMP_P (insn)
|| JUMP_TABLE_DATA_P (insn) /* FIXME */
|| (NONJUMP_INSN_P (insn)
&& (! reload_completed
|| (GET_CODE (PATTERN (insn)) != USE
&& GET_CODE (PATTERN (insn)) != CLOBBER))));
}
