This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, mips] Fix for PR target/56942
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: Steve Ellcey <sellcey at imgtec dot com>
- Cc: <rsandiford at googlemail dot com>, <gcc-patches at gcc dot gnu dot org>, <andrew dot bennett at imgtec dot com>, <stevenb dot gcc at gmail dot com>
- Date: Sat, 27 Apr 2013 08:56:17 +0100
- 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>
Steve Ellcey <sellcey@imgtec.com> writes:
> On Wed, 2013-04-24 at 07:45 +0100, Richard Sandiford wrote:
>> "Steve Ellcey " <sellcey@imgtec.com> writes:
>> > 2013-04-19 Andrew Bennett <andrew.bennett@imgtec.com>
>> > Steve Ellcey <sellcey@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