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.
PR target/83009
* gcc.target/aarch64/store_v2vec_lanes.c: XFAIL for ilp32.
From-SVN: r258894
+2018-03-27 Kyrylo Tkachov <kyrylo.tkachov@arm.com>
+
+ PR target/83009
+ * gcc.target/aarch64/store_v2vec_lanes.c: XFAIL for ilp32.
+
2018-03-27 Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>
PR target/81863
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 } } } */