RE: [PATCH] Allow MIPS call-saved-{4-6}.c tests to correctly run for micromips

["Maciej W. Rozycki" <macro at linux-mips dot org>]

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 care about Octeon or the opposite
> > floatness have to go through the process you describe as "tedious and
> > time consuming".
> > 
> > And you don't avoid that process anyway, since people making changes to
> > target-independent parts of GCC are just as likely to introduce a
> > regression as those making changes to MIPS-only code.  If testing is
> > cheap and takes only a small number of hours, and if you want to make it
> > less tedious to track down a regression, continuous testing would give
> > you a narrow window for each regression.
> > 
> > Submitters should be free to test on what matters to them rather than
> > have to test a canned set of multilibs on specific configurations.
> 
> One of my main concerns is in enabling contribution from less experienced
> developers and those that don't have the infrastructure available to
> perform wide regression testing.

 Common sense applies of course as far as I am concerned.  I'll set 
expectations differently for Joe Random contributing improvements he made 
in his free time than for a company doing it professionally with all the 
infrastructure behind it.

> I would not want to instil fear in anyone that because they didn't test
> a specific ISA/revision then they shouldn't bother submitting their
> patch. The review process is fairly intense in GNU projects and the
> retest of code can easily stack up with just with a few configurations.

 Again, common sense applies.  As soon as *you* are happy with testing, go 
submit your change!  The worst that can happen (again, as far as I am 
concerned) is that I'll ask you if you tested it or can test it for FOO -- 
if I conclude that it is important.  And you can do it if you can, or you 
can say that you don't have the resources for that.  And that will be fine 
-- it'll just mean I'll have to find some time to push it through my 
testing.

 Did you ever see me discourage anyone from submitting any change on any 
basis, BTW?

> On the original issue of micromips...
> I did manage to get round to a test run of micromips for mips.exp today
> and although I haven't checked back in history it looks like we have
> had micromips expected output failures for a significant time. I'll
> try to address some of the failures but don't want to destabilise the
> testsuite for non-micromips at this late stage.

 Thanks!  While at it I wonder whether we shouldn't actually have a third 
variant covering MIPS16e SAVE/RESTORE sequences too.  AFAICT we only have 
legacy MIPS16 covered (isa_rev=0).

  Maciej