Hi all,
The test in question fails for ilp32. The initial analysis I did in the PR for
it
is that for ILP32 we generate somewhat different address forms that we'd need
to adjust aarch64_classify_address to catch.
Given the optimisation this test checks for was added for GCC 8 it is not a
regression, and improving the codegen on ILP32
would be an enhancement rather than a fix. So Richi has asked for it to be
marked as XFAIL on ILP32, which is what this
patch does.
Checked that the test still passes on LP64 and appears as XFAIL on -mabi=ilp32.
Ok for trunk?
Thanks,
Kyrill
2018-03-27 Kyrylo Tkachov <kyrylo.tkac...@arm.com>
PR target/83009
* gcc.target/aarch64/store_v2vec_lanes.c: XFAIL for ilp32.
commit 39e1ef03918b1911cedae37552cbaf1185420aa2
Author: Kyrylo Tkachov <kyrylo.tkac...@arm.com>
Date: Tue Mar 27 10:45:04 2018 +0100
[AArch64] XFAIL gcc.target/aarch64/store_v2vec_lanes.c for ILP32
diff --git a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
index 6810db3..990aea3 100644
--- a/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
+++ b/gcc/testsuite/gcc.target/aarch64/store_v2vec_lanes.c
@@ -26,6 +26,6 @@ construct_lane_2 (long long *y, v2di *z)
values from consecutive memory into a 2-element vector by using
a Q-reg LDR. */
-/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 } } */
-/* { dg-final { scan-assembler-not "ins\t" } } */
+/* { dg-final { scan-assembler-times "stp\td\[0-9\]+, d\[0-9\]+" 1 { xfail ilp32 } } } */
+/* { dg-final { scan-assembler-times "stp\tx\[0-9\]+, x\[0-9\]+" 1 { xfail ilp32 } } } */
+/* { dg-final { scan-assembler-not "ins\t" { xfail ilp32 } } } */
