Steven Bosscher stevenb@gmail.com writes:
On Sat, 2013-04-27 at 08:56 +0100, Richard Sandiford wrote:
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
Hi Richard,
On Sat, 2013-04-27 at 08:56 +0100, Richard Sandiford wrote:
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
Hi Richard,
This (plus inevitable fixes in back-end code,
To: Steve Ellcey; gcc-patches@gcc.gnu.org; Andrew Bennett;
rdsandif...@googlemail.com
Subject: Re: [patch, mips] Fix for PR target/56942
OK for trunk?
If it causes any trouble, please file a PR and assign it to me.
And when the dust has settled, I can clean up the FIXME for
JUMP_TABLE_DATA
And I can't get it to fail. I also can't find any place where the
label and jump table might get separated. I was expecting some trouble
with cross-jumping but it seems that it takes care of updating the
label reference, and skip_insns_after_block already expects the label
and table to be
On Thu, 2013-05-30 at 00:15 +0200, Steven Bosscher wrote:
And I can't get it to fail. I also can't find any place where the
label and jump table might get separated. I was expecting some trouble
with cross-jumping but it seems that it takes care of updating the
label reference, and
On Tue, May 28, 2013 at 10:39 PM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi Steven,
Steven Bosscher stevenb@gmail.com writes:
Imho the active-insn idiom is the best solution for the moment. I
will
On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
rdsandif...@googlemail.com wrote:
Hi Steven,
Steven Bosscher stevenb@gmail.com writes:
Imho the active-insn idiom is the best solution for the moment. I
will fix this mess properly asap, probably next week.
Just wondering, how are
On Tue, 2013-04-30 at 15:05 +0100, Richard Sandiford wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Steven Bosscher stevenb@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
Steve Ellcey sell...@imgtec.com writes:
OK, here is patch to next_real_insn to keep the ordering property intact
and fix the bug. OK for checkin?
Thanks, looks good to me, but an rtl/middle-end/global maintainer
would need to approve it.
Richard
(Top post is gmail's fault ;-)
Hello,
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. Before my patch most
ports used the active variants and I specifically did
Steven Bosscher stevenb@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
Richard Sandiford rdsandif...@googlemail.com writes:
Steven Bosscher stevenb@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
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
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
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
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
Andrew Bennett found this fix to my MIPS build problem (PR target/56942).
He does not have write access so I am submitting it for checkin, is this
a simple enough fix for an 'obvious' checkin? I did a build and regression
test to verify the fix.
Steve Ellcey
sell...@imgtec.com
2013-04-19
17 matches
Mail list logo
