https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286
Tamar Christina <tnfchris at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2025-03-17
Ever confirmed|0 |1
Component|target |testsuite
--- Comment #2 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #1)
> (In reply to Thomas Schwinge from comment #0)
> > I found commit r15-7886-g2427793af1e545506e0315f8ec06adf73d76b3cc
> > "middle-end: delay checking for alignment to load [PR118464]" responsible
> > for a number of GCN target (tested '-march=gfx908') regressions (or new
> > FAILs for the new test cases): [...]
>
> ..., and similarly -- but not identical! -- for '-march=gfx1100':
Only difference is this one..
>
> PASS: gcc.dg/vect/vect-early-break_18.c (test for excess errors)
> [-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_18.c
> [-scan-tree-dump-]{+scan-tree-dump-not+} vect "LOOP VECTORIZED"
>
.. which is an interesting one, as the GCN target doesn't support load lanes,
so the testcase is expected to fail, other targets create a permuted load here
which we then then reject.
This GCN arch instead doesn't seem to support the permuted loads either, so the
vectorizer tries a gather/scatter. But the indices aren't supported by the
target, so instead the vectorizer scalarizes the loads.
So the failure conditions are a bit unique.. I'm surprised the target's costing
didn't reject such a large scalarization though. (it creates 64 scalar loads to
then form a vector from them).
I'm not yet sure how to best check for this... It might be easier to find a new
testcase.
