:d3d198940e5b527e76da7282cc2ce59045b4844, r11-8940 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lbz_cmpldi_cr0_QI_clobber_CCUNS_zero 2 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lha_cmpdi_cr0_HI_clobber_CC_sign 8 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lhz_cmpldi_cr0_HI_clobber_CCUNS_zero 2 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lwa_cmpdi_cr0_SI_EXTSI_CC_sign 3 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lwz_cmpldi_cr0_SI_EXTSI_CCUNS_zero 2 FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):DI \\(reg:[SD]I" 1 FAIL: gcc.target/powerpc/pr81348.c scan-assembler \\mlxsihzx\\M FAIL: gcc.target/powerpc/pr81348.c scan-assembler \\mvextsh2d\\M FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mlwz\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mplwz\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mpstw\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mstw\\M 2 These may just be tests that require adjusting the instruction counts to account for the changes introduced by this commit. commit 7d3d198940e5b527e76da7282cc2ce59045b4844 (HEAD, refs/bisect/bad) Author: Haochen Gui <guihaoc@gcc.gnu.org> Date: Fri Jun 4 11:04:31 2021 +0800 rs6000: Expand PROMOTE_MODE marco in rs6000_promote_function_mode
For pr81348.c, it was already fixed by r11-8941. Segher backported it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100952#c12 PASS: gcc.target/powerpc/pr81348.c (test for excess errors) PASS: gcc.target/powerpc/pr81348.c scan-assembler \\mlha\\M PASS: gcc.target/powerpc/pr81348.c scan-assembler \\mmtvsrwa\\M
What's the status on the remaining failures?
Looking at my 6 days old powerpc64le-linux testresults, I see from gcc.target/powerpc/ FAILures FAIL: gcc.target/powerpc/compress-float-ppc-pic.c scan-assembler lfs FAIL: gcc.target/powerpc/compress-float-ppc.c scan-assembler lfs FAIL: gcc.target/powerpc/fusion-p10-stst.c scan-assembler-times std 4,8\\\\(3\\\\)\\\\n\\\\tstd 6,16\\\\(3\\\\) 1 FAIL: gcc.target/powerpc/fusion-p10-stst.c scan-assembler-times stfd 1,8\\\\(3\\\\)\\\\n\\\\tstfd 3,16\\\\(3\\\\) 1 FAIL: gcc.target/powerpc/fusion-p10-stst.c scan-assembler-times stw 4,4\\\\(3\\\\)\\\\n\\\\tstw 6,8\\\\(3\\\\) 1 FAIL: gcc.target/powerpc/lhs-1.c scan-assembler-times nop 3 FAIL: gcc.target/powerpc/lhs-2.c scan-assembler ori 1,1,0 FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\\\(compare:CC \\\\((?:and|zero_extend):(?:DI) \\\\((?:sub)?reg:[SD]I" 1 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mlwz\\\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mplwz\\\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mpstw\\\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mstw\\\\M 2 FAIL: gcc.target/powerpc/rlwimi-2.c scan-assembler-times (?n)^\\\\s+[a-z] 20217 FAIL: gcc.target/powerpc/rs6000-fpint.c scan-assembler-not stfiwx Comparing with GCC 11.1.0 results, that is +FAIL: gcc.target/powerpc/fusion-p10-stst.c scan-assembler-times std 4,8\\\\(3\\\\)\\\\n\\\\tstd 6,16\\\\(3\\\\) 1 +FAIL: gcc.target/powerpc/fusion-p10-stst.c scan-assembler-times stfd 1,8\\\\(3\\\\)\\\\n\\\\tstfd 3,16\\\\(3\\\\) 1 +FAIL: gcc.target/powerpc/fusion-p10-stst.c scan-assembler-times stw 4,4\\\\(3\\\\)\\\\n\\\\tstw 6,8\\\\(3\\\\) 1 +FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\\\(compare:CC \\\\((?:and|zero_extend):(?:DI) \\\\((?:sub)?reg:[SD]I" 1 +FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mlwz\\\\M 2 +FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mplwz\\\\M 2 +FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mpstw\\\\M 2 +FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\\\mstw\\\\M 2 regression.
(In reply to Richard Biener from comment #2) > What's the status on the remaining failures? For pr56605.c，I already submitted a patch. Waiting for review. https://gcc.gnu.org/pipermail/gcc-patches/2022-February/590958.html
For prefix-no-update.c, the patch Segher proposed in PR103197 could fix it.
I confirm that segher's patch restores the expected insns in prefix-no-update.
The master branch has been updated by Alexandre Oliva <aoliva@gcc.gnu.org>: https://gcc.gnu.org/g:6b7cc7294770ecb57c0f3a116a27ce1aaff170b5 commit r12-8128-g6b7cc7294770ecb57c0f3a116a27ce1aaff170b5 Author: Alexandre Oliva <oliva@adacore.com> Date: Tue Apr 12 22:41:45 2022 -0300 ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146] The test expects a compare of DImode values, but after the removal of PROMOTE_MODE from rs6000/, we get SImode. Adjust the expectations. for gcc/testsuite/ChangeLog PR target/102146 * gcc.target/powerpc/pr56605.c: Accept SImode compare operand.
Defered to 11.4.
Could you backport the patch to GCC11? Thanks.
(In reply to HaoChen Gui from comment #9) > Could you backport the patch to GCC11? Thanks. Please ignore it as the patch has problem. Thanks.
The master branch has been updated by Segher Boessenkool <segher@gcc.gnu.org>: https://gcc.gnu.org/g:26fa464f42622c60d6929720dd37143a21054ede commit r12-8221-g26fa464f42622c60d6929720dd37143a21054ede Author: Segher Boessenkool <segher@kernel.crashing.org> Date: Sun Jan 2 14:08:35 2022 +0000 rs6000: Disparage lfiwzx and similar RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is problematic because the integer load and store insns can use cheaper addressing modes. We can fix that by putting a small penalty on the instruction alternatives for those. 2022-04-21 Segher Boessenkool <segher@kernel.crashing.org> PR target/103197 PR target/102146 * config/rs6000/rs6000.md (zero_extendqi<mode>2 for EXTQI): Disparage the "Z" alternatives in {l,st}{f,xs}iwzx. (zero_extendhi<mode>2 for EXTHI): Ditto. (zero_extendsi<mode>2 for EXTSI): Ditto. (*movsi_internal1): Ditto. (*mov<mode>_internal1 for QHI): Ditto. (movsd_hardfloat): Ditto.
The master branch has been updated by Segher Boessenkool <segher@gcc.gnu.org>: https://gcc.gnu.org/g:748d46cd049c89a799f99f14547267ebae915af6 commit r12-8222-g748d46cd049c89a799f99f14547267ebae915af6 Author: Segher Boessenkool <segher@kernel.crashing.org> Date: Thu Apr 21 18:35:32 2022 +0000 rs6000/testsuite: xfail bswap-brw.c This testcase does not generate anywhere near optimal code for 32-bit code. For p10 it actually now fails this testcase, after the previous patch. Let's xfail it. 2022-04-21 Segher Boessenkool <segher@kernel.crashing.org> gcc/testsuite/ PR target/103197 PR target/102146 * gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32.
What's the status of these test cases now, given all of the fizes applied so far? Can we marked this as FIXED?
(In reply to Peter Bergner from comment #13) > What's the status of these test cases now, given all of the fizes applied so > far? Can we marked this as FIXED? Ping.
As r12-8128 was revoked, failure of pr56605.c is still not fixed.
The releases/gcc-11 branch has been updated by Segher Boessenkool <segher@gcc.gnu.org>: https://gcc.gnu.org/g:2eb21e7349cda2885438463f045f6729a47039e8 commit r11-10207-g2eb21e7349cda2885438463f045f6729a47039e8 Author: Segher Boessenkool <segher@kernel.crashing.org> Date: Sun Jan 2 14:08:35 2022 +0000 rs6000: Disparage lfiwzx and similar RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is problematic because the integer load and store insns can use cheaper addressing modes. We can fix that by putting a small penalty on the instruction alternatives for those. 2022-04-21 Segher Boessenkool <segher@kernel.crashing.org> PR target/103197 PR target/102146 * config/rs6000/rs6000.md (zero_extendqi<mode>2 for EXTQI): Disparage the "Z" alternatives in {l,st}{f,xs}iwzx. (zero_extendhi<mode>2 for EXTHI): Ditto. (zero_extendsi<mode>2 for EXTSI): Ditto. (*movsi_internal1): Ditto. (*mov<mode>_internal1 for QHI): Ditto. (movsd_hardfloat): Ditto. (cherry picked from commit 26fa464f42622c60d6929720dd37143a21054ede)
The releases/gcc-11 branch has been updated by Segher Boessenkool <segher@gcc.gnu.org>: https://gcc.gnu.org/g:72cf56c7cfefaf1b074bb70e42890cf1191c46a1 commit r11-10208-g72cf56c7cfefaf1b074bb70e42890cf1191c46a1 Author: Segher Boessenkool <segher@kernel.crashing.org> Date: Thu Apr 21 18:35:32 2022 +0000 rs6000/testsuite: xfail bswap-brw.c This testcase does not generate anywhere near optimal code for 32-bit code. For p10 it actually now fails this testcase, after the previous patch. Let's xfail it. 2022-04-21 Segher Boessenkool <segher@kernel.crashing.org> gcc/testsuite/ PR target/103197 PR target/102146 * gcc.target/powerpc/bswap-brw.c: Add xfail on scan-assembler for -m32. (cherry picked from commit 748d46cd049c89a799f99f14547267ebae915af6)
The releases/gcc-10 branch has been updated by Segher Boessenkool <segher@gcc.gnu.org>: https://gcc.gnu.org/g:d99d74d8b1b517784e3b05b271b977eb6603121f commit r10-10948-gd99d74d8b1b517784e3b05b271b977eb6603121f Author: Segher Boessenkool <segher@kernel.crashing.org> Date: Sun Jan 2 14:08:35 2022 +0000 rs6000: Disparage lfiwzx and similar RA now chooses GEN_OR_VSX_REGS in most cases. This is great in most cases, but we often (or always?) use {l,st}{f,xs}iwzx now, which is problematic because the integer load and store insns can use cheaper addressing modes. We can fix that by putting a small penalty on the instruction alternatives for those. 2022-04-21 Segher Boessenkool <segher@kernel.crashing.org> PR target/103197 PR target/102146 * config/rs6000/rs6000.md (zero_extendqi<mode>2 for EXTQI): Disparage the "Z" alternatives in {l,st}{f,xs}iwzx. (zero_extendhi<mode>2 for EXTHI): Ditto. (zero_extendsi<mode>2 for EXTSI): Ditto. (*movsi_internal1): Ditto. (*mov<mode>_internal1 for QHI): Ditto. (movsd_hardfloat): Ditto. (cherry picked from commit 26fa464f42622c60d6929720dd37143a21054ede)
Hi guys, What testcases are still failing? I'm a bit lost :-)
(In reply to Segher Boessenkool from comment #19) > Hi guys, > > What testcases are still failing? I'm a bit lost :-) pr56605.c is still not fixed. +FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\\\(compare:CC \\\\((?:and|zero_extend):(?:DI) \\\\((?:sub)?reg:[SD]I" 1
Closing as fixed then (pr56605.c still fails on older branches, but that is harmless).
The master branch has been updated by HaoChen Gui <guihaoc@gcc.gnu.org>: https://gcc.gnu.org/g:0580ea4b7a6dc8ee981b08f936b3ce62c6dfe200 commit r13-6981-g0580ea4b7a6dc8ee981b08f936b3ce62c6dfe200 Author: Haochen Gui <guihaoc@gcc.gnu.org> Date: Fri Mar 31 12:51:32 2023 +0800 rs6000: Modify test case after mode promotion disabled gcc/testsuite/ PR target/102146 * gcc.target/powerpc/pr56605.c: Modify the match pattern for dump scan.
*** Bug 105267 has been marked as a duplicate of this bug. ***