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
