"Maciej W. Rozycki" <ma...@codesourcery.com> writes: > On Tue, 16 Jul 2013, Richard Sandiford wrote: > >> > I have regression-tested this change with the mips-linux-gnu target and >> > the mips32r2/o32 multilib. I have also verified that the instructions >> > affected were absent across the binaries produced by the testsuite before >> > applying this change and present afterwards. For some reason only MADD.S, >> > MADD.D, MSUB.S and MSUB.D instructions were produced though -- it looks >> > like none of NMADD.S, NMADD.D, NMSUB.S and NMSUB.D instructions has >> > coverage in our testsuite. >> >> Hmm, can you double-check? We have gcc.target/mips/nmadd-*, so if we're >> not producing the instructions there then that sounds like a bug. > > I only checked executables, these tests do not produce any. I didn't > think of checking tests that do not produce executables, because they do > not check run-time validity of code produced. These three tests you've > referred to all pass with or without the change, but they are tangential > to it because they all force -mips4.
OK, as long as those tests pass then the patch is OK, thanks. They aren't tangential for a -march=vr5400 run though. The tests force isa=4 rather than -mips4, and since the VR5432 is a MIPS IV processor, the tests will be run with that -march value. E.g. make check-gcc RUNTESTFLAGS="--target_board unix/-march=vr5400 mips.exp=nmadd*" fails for me but: make check-gcc RUNTESTFLAGS="--target_board unix/-march=vr5400/-mmad mips.exp=nmadd*" passes. Richard
