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 suite I'd rather see the test cases updated > > > so that LWM/SWM register ranges are expected and accepted whenever > > > microMIPS code is produced. These scan patterns can be made > > conditional. > > > > FWIW I think Andrew's patch is correct. If we want to test microMIPS > > output against micromips-specific regexps, we should add a separate test > > that forces micromips, so that it gets tested regardless of people's > > RUNTESTFLAGS. Doing that shouldn't hold up Andrew's patch though.
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? > > Whereever possible gcc.target/mips should not have conditional dg- > > finals. OK, if that's been the policy. > I was going to suggest a follow up patch to add copies of the three tests > as Richard suggests. I haven't yet done a micromips run of the testsuite > to check for any other issues like this but I suspect problems are limited > to the tests that I recently added. Please always try to test changes reasonably, i.e. at least o32, o32/MIPS16, o32/microMIPS, n32, n64, and then Linux and ELF if applicable, plus any options that may be relevant, unless it is absolutely clear ABI/ISA variations do not matter for a change proposed. Running regression tests is just processing time after all (cheap!), you don't have to spend your brain cycles on it (expensive!). Maciej
