Steven Bosscher 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
PM
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_DA
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 skip_in
> 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 Tue, May 28, 2013 at 10:39 PM, Steven Bosscher wrote:
> On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
> wrote:
>> Hi Steven,
>>
>> Steven Bosscher writes:
>>> Imho the active-insn "idiom" is the best solution for the moment. I
>>> will fix this mess properly asap, probably next week.
>>
On Tue, May 28, 2013 at 9:36 PM, Richard Sandiford
wrote:
> Hi Steven,
>
> Steven Bosscher 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 things going with this? (I assume fixing
Hi Steven,
Steven Bosscher 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 things going with this? (I assume fixing it
properly means getting rid of the FIXME in next_active_insn?)
Tha
Hello,
I'm on holiday, but I'm back home tomorrow.
Imho the active-insn "idiom" is the best solution for the moment. I
will fix this mess properly asap, probably next week.
Ciao!
Steven
On 5/3/13, Steve Ellcey wrote:
> On Tue, 2013-04-30 at 15:05 +0100, Richard Sandiford wrote:
>> Richard Sa
On Tue, 2013-04-30 at 15:05 +0100, Richard Sandiford wrote:
> Richard Sandiford writes:
> > Steven Bosscher 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
Richard Sandiford writes:
> Steven Bosscher 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
Steven Bosscher 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
(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
Steve Ellcey 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
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
Steve Ellcey writes:
> On Wed, 2013-04-24 at 07:45 +0100, Richard Sandiford wrote:
>> "Steve Ellcey " writes:
>> > 2013-04-19 Andrew Bennett
>> >Steve Ellcey
>> >
>> >PR target/56942
>> >* config/mips/mips.md (casesi_internal_mips16_): Use
>> >next_active_insn instead of n
On Wed, 2013-04-24 at 07:45 +0100, Richard Sandiford wrote:
> "Steve Ellcey " writes:
> > 2013-04-19 Andrew Bennett
> > Steve Ellcey
> >
> > PR target/56942
> > * config/mips/mips.md (casesi_internal_mips16_): Use
> > next_active_insn instead of next_real_insn.
>
> Hmm, I
"Steve Ellcey " writes:
> 2013-04-19 Andrew Bennett
> Steve Ellcey
>
> PR target/56942
> * config/mips/mips.md (casesi_internal_mips16_): 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/bu
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 Andr
19 matches
Mail list logo
