On Wed, 14 Jan 2015, Matthew Fortune wrote:
> > Yeah, but that's just the way it goes. By trying to get everyone to
> > test with the options that matter to you, you're reducing the amount of
> > work you have to do when tracking regressions on those targets, but
> > you're saying that people who
On Wed, 14 Jan 2015, Richard Sandiford wrote:
> >> The aim of mips.exp is avoid skipping tests whereever possible. If
> >> someone runs the testsuite with -mips16 and we have a -micromips test,
> >> it's better to remove -mips16 for that test than to skip the test entirely.
> >
> > OK, good to k
> I have tested this for both mips and micromips, and the tests now pass
> successfully.
> The ChangeLog and patch are below.
>
> Ok to commit?
Since you had not got to committing this yet. I have added the micromips
variants of the tests and committed your patch for you. Thanks for
finding the
Richard Sandiford writes:
> "Maciej W. Rozycki" writes:
> > On Wed, 14 Jan 2015, Richard Sandiford wrote:
> >> I think we just have to accept that there are so many possible
> >> combinations that we can't test everything that's potentially
> relevant.
> >> I think it's more useful to be flexible
"Maciej W. Rozycki" writes:
> On Wed, 14 Jan 2015, Richard Sandiford wrote:
>
>> > Taking care that the default compilation mode does not conflict (e.g.
>> > MIPS16, incompatible) and taking any exceptions into account (e.g. n64,
>> > unsupported) I presume, right?
>>
>> mips.exp sorts that ou
On Wed, 14 Jan 2015, Richard Sandiford wrote:
> > Taking care that the default compilation mode does not conflict (e.g.
> > MIPS16, incompatible) and taking any exceptions into account (e.g. n64,
> > unsupported) I presume, right?
>
> mips.exp sorts that out for you. Adding "-mmicromips" or "
"Maciej W. Rozycki" writes:
> On Tue, 13 Jan 2015, Matthew Fortune wrote:
>
>> > >> I have tested this for both mips and micromips, and the tests now
>> > >> pass successfully.
>> > >> The ChangeLog and patch are below.
>> > >
>> > > Hmm, instead of trying to avoid testing microMIPS code generati
On Tue, 13 Jan 2015, Matthew Fortune wrote:
> > >> I have tested this for both mips and micromips, and the tests now
> > >> pass successfully.
> > >> The ChangeLog and patch are below.
> > >
> > > Hmm, instead of trying to avoid testing microMIPS code generation
> > > just to satisfy the test sui
Richard Sandiford writes:
> "Maciej W. Rozycki" writes:
> > On Tue, 13 Jan 2015, Andrew Bennett wrote:
> >
> >> The call-saved-{4-6}.c tests in the mips testsuite fail for
> micromips.
> >> The reason is
> >> that micromips uses the swm and lwm instructions to save/restore the
> >> call-saved re
"Maciej W. Rozycki" writes:
> On Tue, 13 Jan 2015, Andrew Bennett wrote:
>
>> The call-saved-{4-6}.c tests in the mips testsuite fail for micromips.
>> The reason is
>> that micromips uses the swm and lwm instructions to save/restore the
>> call-saved registers
>> rather than using the sw and lw i
On Tue, 13 Jan 2015, Andrew Bennett wrote:
> The call-saved-{4-6}.c tests in the mips testsuite fail for micromips. The
> reason is
> that micromips uses the swm and lwm instructions to save/restore the
> call-saved registers
> rather than using the sw and lw instructions. The swm and lwm in
Hi,
The call-saved-{4-6}.c tests in the mips testsuite fail for micromips. The
reason is
that micromips uses the swm and lwm instructions to save/restore the call-saved
registers
rather than using the sw and lw instructions. The swm and lwm instructions
only list
the range of registers to
12 matches
Mail list logo
