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: Steven Bosscher <stevenb dot gcc at gmail dot com>
- Cc: Steve Ellcey <sellcey at imgtec dot com>, gcc-patches at gcc dot gnu dot org, andrew dot bennett at imgtec dot com
- Date: Tue, 30 Apr 2013 14:28:33 +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> <87ehdwiezi dot fsf at talisman dot default> <1367266413 dot 8625 dot 3 dot camel at ubuntu-sellcey> <87mwsgh5eb dot fsf at talisman dot default> <CABu31nPa0i7MMzqf4tJ2Vh25nEQUkHoboXKk32y04OrPN2hL4w at mail dot gmail dot com>
Steven Bosscher <stevenb.gcc@gmail.com> writes:
> I dont like this at all. At the very least, if we go this way,
> then all places where next_active_insn is used should be updated.
> Otherwise this is just confusion proliferation.
You mean all places where next_active_insn is used to get the jump table?
That would be fine with me, but as author of the original change,
I'm going to ask you to do that if you feel strongly about it :-)
Otherwise Steve's patch seems fine to me.
> Before my patch most
> ports used the "active" variants and I specifically did non fix the
> "real" variants. It is marked fixme for a reason: The JUMP_TABLE_DATA
> should always follow immediately after the label. Copying the fixme is
> a step in the wrong direction. Please do not commit this patch!
But you didn't respond to my main point. It always used to be the
case that all "active" insns were also "real". I.e. "real" was a
_more_ restrictive condition than "active". Having insns that are
"active" but not "real" is a change to the interface and also
(IMO) doesn't make much sense in terms of English usage.
Don't get me wrong: I like the change to use something other
than JUMP_INSN to store the jump table, and thanks for making it.
I just don't think we should "break" the next_*_insn hierachy at
the same time.
Richard