This XFAILs the gcc.target/i386/pr109362.c testcase where we now
need an additional register for the address part of a sequence
of two atomic loads because TER no longer applies after we now
hoist the address computation out of a loop. In the PR I noted
how RTL propagation could handle this. In the end this restores
the state we had in GCC 12 and earlier where in GCC 13 the code
generation improved by accident.
This resolves a P1 testsuite regression.
OK for trunk?
Thanks,
Richard.
PR rtl-optimization/119982
* gcc.target/i386/pr109362.c: XFAIL.
---
gcc/testsuite/gcc.target/i386/pr109362.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.target/i386/pr109362.c
b/gcc/testsuite/gcc.target/i386/pr109362.c
index 0e44dae0389..445a3ccdd38 100644
--- a/gcc/testsuite/gcc.target/i386/pr109362.c
+++ b/gcc/testsuite/gcc.target/i386/pr109362.c
@@ -3,7 +3,7 @@
/* { dg-options "-O2 -masm=att" } */
/* Ensure we don't waste a register set to %rdi + 8. */
/* { dg-final { scan-assembler "\tmovq\t\\\(%rdi\\\), %r" } } */
-/* { dg-final { scan-assembler "\tmovq\t8\\\(%rdi\\\), %r" } } */
+/* { dg-final { scan-assembler "\tmovq\t8\\\(%rdi\\\), %r" { xfail *-*-* } } }
*/
struct S { long a, b; };
--
2.51.0
