https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94812
--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Alexandre Oliva <aol...@gcc.gnu.org>: https://gcc.gnu.org/g:50714f45eeaf315a0b55d3db3de3bf8df8e94b04 commit r10-8020-g50714f45eeaf315a0b55d3db3de3bf8df8e94b04 Author: Alexandre Oliva <ol...@adacore.com> Date: Thu Apr 23 02:19:55 2020 -0300 [rs6000] fix mffsl emulation The emulation of mffsl with mffs, used when !TARGET_P9_MISC, is going through the motions, but not storing the result in the given operands[0]; it rather modifies operands[0] without effect. It also creates a DImode pseudo that it doesn't use, overwriting subregs instead. The patch below fixes all of these, the indentation and a typo. I'm concerned about several issues in the mffsl testcase. First, I don't see that comparing the values as doubles rather than as long longs is desirable. These are FPSCR bitfields, not FP numbers. I understand mffs et al use double because they output to FP registers, and the bit patterns are subnormal FP numbers, so it works, but given the need for bit masking of at least one side, I'm changing the compare to long longs. Another issue with the test is that, if the compare fails, it calls mffsl again to print the value, as if it would yield the same result. But part of the FPSCR that mffsl (emulated with mffs or not) copies to the output FP register is the FPCC, so the fcmpu used to compare the result of the first mffsl will modify FPSCR and thus the result of the second mffsl call. After changing the compare, this is no longer the case, but I still think it's better to make absolutely sure what we print is what we compared. Yet another issue is that the test assumed the mffs bits that are not to be extracted by mffsl to be already zero, instead of masking them out explicitly. This is not about the mffs emulation in the mffsl implementation, but about the mffs use in the test proper. The bits appear to be zero indeed, as the bits left out are for sticky exceptions, but there are reserved parts of FPSCR that might turn out to be set in the future, so we're better off masking them out explicitly, otherwise those bits could cause the compare to fail. If some future mffsl is changed so that it copies additional nonzero bits, the test will fail, and then we'll have a chance to adjust it and the emulation. for gcc/ChangeLog PR target/94812 * gcc/config/rs6000/rs6000.md (rs6000_mffsl): Copy result to output operand in emulation. Don't overwrite pseudos. for gcc/testsuite/ChangeLog PR target/94812 * gcc.target/powerpc/test_mffsl.c: Call mffsl only once. Reinterpret the doubles as long longs for compares. Mask out mffs bits that are not expected from mffsl.
