https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119286
--- Comment #9 from Tamar Christina <tnfchris at gcc dot gnu.org> ---
(In reply to Thomas Schwinge from comment #8)
> Tamar, thanks! I confirm all fixed -- but one:
>
> (In reply to myself from comment #1)
> > ..., and similarly -- but not identical! -- for '-march=gfx1100':
>
> > PASS: gcc.dg/vect/vect-early-break_38.c (test for excess errors)
> > [-PASS:-]{+FAIL:+} gcc.dg/vect/vect-early-break_38.c
> > [-scan-tree-dump-]{+scan-tree-dump-not+} vect "vectorized 1 loops in
> > function"
>
> Which cure does that one need?
oh I hadn't realized that the cause for that test for -march-gfx1100 was
different than for gfx908.
vect-early-break_38.c:15:20: missed: unsupported vect permute { 0 2 4 6 8 10
12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52 54 56 58 60 62
64 66 68 70 72 74 76 78 80 82 84 86 88 90 92 94 96 98 100 102 104 106 108 110
112 114 116 118 120 122 124 126 }
vect-early-break_38.c:15:20: missed: single-element interleaving permutation
not supported, using elementwise access
It's scalarizing the loads again so the fix is the same as
vect-early-break_18.c
in that it needs a consistent architecture. -march=gfx908 is testing what the
test was intended to test.
