This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
- From: Richard Sandiford <rdsandiford at googlemail dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>
- Cc: Steve Ellcey <Steve dot Ellcey at imgtec dot com>, "gcc-patches\ at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 16 Jul 2013 21:05:30 +0100
- Subject: Re: [PATCH v2] MIPS: MIPS32r2 FP MADD instruction set support
- References: <alpine dot DEB dot 1 dot 10 dot 1302200035560 dot 6762 at tp dot orcam dot me dot uk> <871ucavy5x dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1302211602400 dot 6762 at tp dot orcam dot me dot uk> <1C0E790D7E4C75418622FD04CC2A1172015D6DAF at bamail02 dot ba dot imgtec dot org> <87obf5eedo dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1302271951120 dot 6762 at tp dot orcam dot me dot uk> <alpine dot DEB dot 1 dot 10 dot 1307160205590 dot 20590 at tp dot orcam dot me dot uk> <87vc4axrr5 dot fsf at talisman dot default> <alpine dot DEB dot 1 dot 10 dot 1307162025230 dot 20590 at tp dot orcam dot me dot uk>
"Maciej W. Rozycki" <macro@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