Steve Ellcey <sell...@imgtec.com> writes:
> 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.
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
