On Tue, Mar 27, 2018 at 02:39:12PM +0100, Kyrill Tkachov wrote:
> 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?
This would count under the obvious rule.
OK.
Thanks,
James
> 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 } } } */
