https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88834
--- Comment #22 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to kugan from comment #21)
> (In reply to Christophe Lyon from comment #20)
> > Hi Kugan,
> >
> > The new test fails with -mabi=ilp32:
> > FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tld2w\\t{z[0-9]+.s
> > - z[0-9]+.s}, p[0-7]/z, \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 2
> > FAIL: gcc.target/aarch64/pr88834.c scan-assembler-times \\tst2w\\t{z[0-9]+.s
> > - z[0-9]+.s}, p[0-7], \\[x[0-9]+, x[0-9]+, lsl 2\\]\\n 1
>
> Thanks Christophe. In the back-end, when we use ILP32, we don't accept
> SImode ops if like:
>
> (plus:SI (mult:SI (reg:SI 91)
> (const_int 4 [0x4]))
> (reg:SI 90))
>
> While we would accept Pmode. My question is, should we care about ILP32 for
> SVE? If so we need to fix this. Otherwise, we can run the test for LP64.
We care, but I don't think anyone's actively working on it.
I agree it's a generic ILP32 problem though. We already disable
scan-assembler matching in sve/ for similar reasons, so I think the
easiest fix is to move both pr88834.c and pr88838.c from aarch64/ to
aarch64/sve/. Sorry for not noticing that they were in the "wrong"
directory during the reviews.
Note that after moving, the dg-options for both tests should just
be "-O3", without "-S" or "-march=...".
