[Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits

[Bug libgomp/102789] New: [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

            Bug ID: 102789
           Summary: [12 regression] libgomp.c++/simd-3.C fails after
                    r12-xxxx for 32 bits
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

g:fab2f61dc1b195fec9161be15635b87d312e4626, r12-4340
make  -k check-target-libgomp RUNTESTFLAGS="--target_board=unix'{-m32}'
c++.exp=libgomp.c++/simd-3.C"
FAIL: libgomp.c++/simd-3.C execution test
# of expected passes            1
# of unexpected failures        1

I couldn't get a traceback of where it failed other than it was in main.

commit fab2f61dc1b195fec9161be15635b87d312e4626
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Oct 12 09:28:10 2021 +0200

    vectorizer: Fix up -fsimd-cost-model= handling

[Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-xxxx for 32 bits

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

seurer at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |powerpc64-linux-gnu
               Host|                            |powerpc64-linux-gnu
              Build|                            |powerpc64-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
Oh, seen on a power 7 BE host.

[Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |12.0

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
          Component|libgomp                     |target
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-10-18
                 CC|                            |dje at gcc dot gnu.org,
                   |                            |segher at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I can reproduce, but only with -mcpu=power7.  The cost model patch just
uncovered a latent power7 vectorization bug (backend or vectorizer) I'd say.
I've instrumented the testcase a little bit:
// { dg-do run }
// { dg-additional-options "-msse2" { target sse2_runtime } }
// { dg-additional-options "-mavx" { target avx_runtime } }

extern "C" void abort ();
int a[1024] __attribute__((aligned (32))) = { 1 };
int b[1024] __attribute__((aligned (32))) = { 1 };
unsigned char c[1024] __attribute__((aligned (32))) = { 1 };
int k, m;
__UINTPTR_TYPE__ u, u2, u3;

__attribute__((noinline, noclone)) int
foo (int *p)
{
  int i, s = 0, s2 = 0, t, t2;
  #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \
                   lastprivate (t2)
  for (i = 0; i < 512; i++)
    {
      a[i] *= p[i];
      t2 = k + p[i];
      k += m + 1;
      s += p[i] + k;
      c[i]++;
    }
  #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
                   lastprivate (t, u, u2, u3)
  for (i = 512; i < 1024; i++)
    {
      a[i] *= p[i];
      k += m + 1;
      t = k + p[i];
      u = (__UINTPTR_TYPE__) &k;
      u2 = (__UINTPTR_TYPE__) &s2;
      u3 = (__UINTPTR_TYPE__) &t;
      s2 += t;
      c[i]++;
    }
__builtin_printf ("foo %d %d %d %d\n", s, s2, t, t2);
  return s + s2 + t + t2;
}

__attribute__((noinline, noclone)) long int
bar (int *p, long int n, long int o)
{
  long int i, s = 0, s2 = 0, t, t2;
  #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s) \
                   lastprivate (t2)
  for (i = 0; i < n; i++)
    {
      a[i] *= p[i];
      t2 = k + p[i];
      k += m + 1;
      s += p[i] + k;
      c[i]++;
    }
  #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
                   lastprivate (t, u, u2, u3)
  for (i = n; i < o; i++)
    {
      a[i] *= p[i];
      k += m + 1;
      t = k + p[i];
      u = (__UINTPTR_TYPE__) &k;
      u2 = (__UINTPTR_TYPE__) &s2;
      u3 = (__UINTPTR_TYPE__) &t;
      s2 += t;
      c[i]++;
    }
__builtin_printf ("bar %d %d %d %d\n", s, s2, t, t2);
  return s + s2 + t + t2;
}

int
main ()
{
#if __SIZEOF_INT__ >= 4
  int i;
  k = 4;
  m = 2;
  for (i = 0; i < 1024; i++)
    {
      a[i] = i - 512;
      b[i] = (i - 51) % 39;
      c[i] = (unsigned char) i;
    }
  int s = foo (b);
  for (i = 0; i < 1024; i++)
    {
      if (b[i] != (i - 51) % 39
          || a[i] != (i - 512) * b[i]
          || c[i] != (unsigned char) (i + 1))
{
__builtin_printf ("#1 %d %d %d %d\n", i, b[i], a[i], c[i]);
        abort ();
}
      a[i] = i - 512;
    }
  if (k != 4 + 3 * 1024
      || s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023]))
{
__builtin_printf ("#2 %d %d\n", k, s);
    abort ();
}
  k = 4;
  s = bar (b, 512, 1024);
  for (i = 0; i < 1024; i++)
    {
      if (b[i] != (i - 51) % 39
          || a[i] != (i - 512) * b[i]
          || c[i] != (unsigned char) (i + 2))
{
__builtin_printf ("#3 %d %d %d %d\n", i, b[i], a[i], c[i]);
        abort ();
}
      a[i] = i - 512;
    }
  if (k != 4 + 3 * 1024
      || s != 1596127 + (4 + 3 * 511 + b[511]) + (4 + 3 * 1024 + b[1023]))
{
__builtin_printf ("#4 %d %d\n", k, s);
    abort ();
}
  k = 4;
  s = bar (b, 511, 1021);
  for (i = 0; i < 1021; i++)
    {
      if (b[i] != (i - 51) % 39
          || a[i] != (i - 512) * b[i]
          || c[i] != (unsigned char) (i + 3))
{
__builtin_printf ("#5 %d %d %d %d\n", i, b[i], a[i], c[i]);
        abort ();
}
      a[i] = i - 512;
    }
  for (i = 1021; i < 1024; i++)
    if (b[i] != (i - 51) % 39
        || a[i] != i - 512
        || c[i] != (unsigned char) (i + 2))
{
__builtin_printf ("#6 %d %d %d %d\n", i, b[i], a[i], c[i]);
      abort ();
}
  if (k != 4 + 3 * 1021
      || s != 1586803 + (4 + 3 * 510 + b[510]) + (4 + 3 * 1021 + b[1020]))
{
__builtin_printf ("#7 %d %d %d %d\n", k, s, b[510], b[1020]);
    abort ();
}
#endif
  return 0;
}

When compiled with -O2 -m32 -fopenmp -mcpu=power6, this prints:
foo 403860 1192267 3112 1568
bar 403860 1192267 3112 1568
bar 402289 1184514 3100 1564
while with -O2 -m32 -fopenmp -mcpu=power7 it prints:
foo 403860 1192267 3112 1568
bar 403860 1192267 3112 1568
bar 402289 919217 3100 1564
#7 3067 1326170 30 33
Aborted
which seems to suggest it is the:
  #pragma omp simd aligned(a, b, p : 32) linear(k: m + 1) reduction(+:s2) \
                   lastprivate (t, u, u2, u3)
  for (i = n; i < o; i++)
    {
      a[i] *= p[i];
      k += m + 1;
      t = k + p[i];
      u = (__UINTPTR_TYPE__) &k;
      u2 = (__UINTPTR_TYPE__) &s2;
      u3 = (__UINTPTR_TYPE__) &t;
      s2 += t;
      c[i]++;
    }
loop that is miscompiled and miscomputes s2.
Now, the loop is invoked twice, once with n = 512 and o = 1024 and in that case
it works fine, and then with n = 511 and o = 1021 and in that case it
misbehaves, so I bet it must be related to the prologue or epilogue loops.

Now, if I compile with -O2 -m32 -fopenmp -mcpu=power7
-fvect-cost-model=unlimited -fsimd-cost-model=unlimited, it is miscompiled the
same way already in r9-1520-g42c5d1212ff6544be1061d488aa7ebee9463c375 (haven't
bisected fully), but certainly r5-370-ged15c5984e10f6556dffdf397accff804bf60a7c
through
r9-1052-gfa725532c41ae543fd0078263ea348aa5af3997d have been ICEing on it
instead:
simd-3.C: In function ‘long int bar(int*, long int, long int)’:
simd-3.C:44:1: internal compiler error: in vect_get_store_cost, at
tree-vect-stmts.c:1123
 bar (int *p, long int n, long int o)
 ^~~
0x1510f87 vect_get_store_cost(_stmt_vec_info*, int, unsigned int*,
vec<stmt_info_for_cost, va_heap, vl_ptr>*)
        ../../gcc/tree-vect-stmts.c:1123
0x1510da0 vect_model_store_cost
        ../../gcc/tree-vect-stmts.c:1057
0x152200b vectorizable_store
        ../../gcc/tree-vect-stmts.c:6396
0x152cbf2 vect_analyze_stmt(gimple*, bool*, _slp_tree*, _slp_instance*,
vec<stmt_info_for_cost, va_heap, vl_ptr>*)
        ../../gcc/tree-vect-stmts.c:9550
0x153a01f vect_analyze_loop_operations
        ../../gcc/tree-vect-loop.c:1655
0x153ad28 vect_analyze_loop_2
        ../../gcc/tree-vect-loop.c:2050
0x153bd78 vect_analyze_loop(loop*, _loop_vec_info*)
        ../../gcc/tree-vect-loop.c:2343
0x157062a vectorize_loops()
        ../../gcc/tree-vectorizer.c:758
0x14196b5 execute
        ../../gcc/tree-ssa-loop.c:414
Note, r5-370 would ICE with it even with just
-O3 -fopenmp -m32 -mcpu=power7 or -O2 -fopenmp -m32 -mcpu=power7
-fvect-cost-model=unlimited.

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
On the trunk, -O2 -fopenmp -mcpu=power6 -maltivec -m32 works fine, while
-O2 -fopenmp -mcpu=power6 -mvsx -m32 is miscompiled too.

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |linkw at gcc dot gnu.org
                 CC|                            |linkw at gcc dot gnu.org

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
I'll have a look first.

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org,
                   |                            |wschmidt at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #5 from Kewen Lin <linkw at gcc dot gnu.org> ---
As Jakub noted, r12-4340 just exposed one latent bug, even without r12-4340 but
with -fvect-cost-model=dynamic, the issue still exists. The key is if it will
do the peeling for alignment in prologue.

          unsigned max_allowed_peel
            = param_vect_max_peeling_for_alignment;
          if (flag_vect_cost_model <= VECT_COST_MODEL_CHEAP)
            max_allowed_peel = 0;

--param vect-max-peeling-for-alignment=14 make the peeling disabled and it
passes.

I think this is a bug in vectorizer, reduced the culprit loop to (also move the
first loop out of function):

  for (i = n; i < o; i++)
    {
      k += m + 1;
      t = k + p[i];
      s2 += t;
      c[i]++;
    }

we have some temporary storages for the omp clause such as:

  int D.3802[16];  // for k
  int D.3800[16];  // for s2
  int D.3799[16];  // for t

After having the peeling (one prologue), the addresses of k,s2,t become to:

  _187 = prolog_loop_niters.27_88 * 4;
  vectp.37_186 = &D.3802 + _187;
  _213 = prolog_loop_niters.27_88 * 4;
  vectp.46_212 = &D.3799 + _213;
  _222 = prolog_loop_niters.27_88 * 4;
  vectp.48_221 = &D.3800 + _222;

then the main vectorized loop body acts on the biased addresses which is wrong:

  vect__61.49_223 = MEM <vector(4) int> [(int *)vectp.48_221];
  vectp.48_224 = vectp.48_221 + 16;
  vect__61.50_225 = MEM <vector(4) int> [(int *)vectp.48_224];
  vectp.48_226 = vectp.48_221 + 32;
  vect__61.51_227 = MEM <vector(4) int> [(int *)vectp.48_226];
  vectp.48_228 = vectp.48_221 + 48;
  vect__61.52_229 = MEM <vector(4) int> [(int *)vectp.48_228];
  _61 = D.3800[_56];

  vect__62.53_230 = vect__59.44_208 + vect__61.49_223;
  vect__62.53_231 = vect__59.44_209 + vect__61.50_225;
  vect__62.53_232 = vect__59.44_210 + vect__61.51_227;
  vect__62.53_233 = vect__59.44_211 + vect__61.52_229;
  _62 = _59 + _61;

  MEM <vector(4) int> [(int *)vectp.55_234] = vect__62.53_230;
  vectp.55_237 = vectp.55_234 + 16;
  MEM <vector(4) int> [(int *)vectp.55_237] = vect__62.53_231;
  vectp.55_239 = vectp.55_234 + 32;
  MEM <vector(4) int> [(int *)vectp.55_239] = vect__62.53_232;
  vectp.55_241 = vectp.55_234 + 48;
  MEM <vector(4) int> [(int *)vectp.55_241] = vect__62.53_233;


A fix looks to avoid the address biasing for these kinds of DRs for omp clause
specific storage. These DRs are mainly used in the main loop (lanes?), for this
case it's for reduction, in prologues we use element 0, in epilogue we use the
last one or reduc_op all elements according to the type. The below small fix
can make it pass:

diff --git a/gcc/tree-vect-loop-manip.c b/gcc/tree-vect-loop-manip.c
index 4988c93fdb6..a447f457f93 100644
--- a/gcc/tree-vect-loop-manip.c
+++ b/gcc/tree-vect-loop-manip.c
@@ -1820,7 +1820,7 @@ vect_update_inits_of_drs (loop_vec_info loop_vinfo, tree
niters,
   FOR_EACH_VEC_ELT (datarefs, i, dr)
     {
       dr_vec_info *dr_info = loop_vinfo->lookup_dr (dr);
-      if (!STMT_VINFO_GATHER_SCATTER_P (dr_info->stmt))
+      if (!STMT_VINFO_GATHER_SCATTER_P (dr_info->stmt) &&
!STMT_VINFO_SIMD_LANE_ACCESS_P (dr_info->stmt))
        vect_update_init_of_dr (dr_info, niters, code);
     }
 }

I've not looked into the meaning for different values (1,2,3,4) for
STMT_VINFO_SIMD_LANE_ACCESS_P (stmt_info), it seems for the different omp
clauses? The assumption of the above fix is that for all cases of
STMT_VINFO_SIMD_LANE_ACCESS_P > 0, the related DR would be used mainly in
vectorized loop body, we don't need any updates for it in prologue. I'm going
to do one broader testing to see if we need more restrictions on that.

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
The proposed patch was tested and just posted at
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/582453.html.

[Bug target/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:f3dbd3f36d55178d0a9e4431043cbc950524969a

commit r12-4697-gf3dbd3f36d55178d0a9e4431043cbc950524969a
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Oct 25 21:05:02 2021 -0500

    vect: Don't update inits for simd_lane_access DRs [PR102789]

    As PR102789 shows, when vectorizer does some peelings for alignment
    in prologues, function vect_update_inits_of_drs would update the
    inits of some drs.  But as the failed case, we shouldn't update the
    dr for simd_lane_access, it has the fixed-length storage mainly for
    the main loop, the update can make the access out of bound and access
    the unexpected element.

    gcc/ChangeLog:

            PR tree-optimization/102789
            * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
            update inits of simd_lane_access.

[Bug tree-optimization/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |tree-optimization
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks Jakub for the review, this should be fixed on latest trunk.

[Bug tree-optimization/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #9 from Kewen Lin <linkw at gcc dot gnu.org> ---
Oops, forgot to ask that whether we want this backport?

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |12.0
   Target Milestone|12.0                        |---
            Summary|[12 regression]             |libgomp.c++/simd-3.C fails
                   |libgomp.c++/simd-3.C fails  |after r12-4340 for 32 bits
                   |after r12-4340 for 32 bits  |

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
If older releases are affected then yes.  Not a 12 regression anymore.

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kewen Lin from comment #9)
> Oops, forgot to ask that whether we want this backport?

Yes, please.

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-9 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:6cce26752d8431a1ef6d3f9a97fa0ee2e9f96816

commit r9-9815-g6cce26752d8431a1ef6d3f9a97fa0ee2e9f96816
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Oct 25 21:05:02 2021 -0500

    vect: Don't update inits for simd_lane_access DRs [PR102789]

    As PR102789 shows, when vectorizer does some peelings for alignment
    in prologues, function vect_update_inits_of_drs would update the
    inits of some drs.  But as the failed case, we shouldn't update the
    dr for simd_lane_access, it has the fixed-length storage mainly for
    the main loop, the update can make the access out of bound and access
    the unexpected element.

    gcc/ChangeLog:

            PR tree-optimization/102789
            * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
            update inits of simd_lane_access.

    (cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a)

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:4f024c99a05f1c6852d1e5daad4a172f4cdd24a1

commit r10-10257-g4f024c99a05f1c6852d1e5daad4a172f4cdd24a1
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Oct 25 21:05:02 2021 -0500

    vect: Don't update inits for simd_lane_access DRs [PR102789]

    As PR102789 shows, when vectorizer does some peelings for alignment
    in prologues, function vect_update_inits_of_drs would update the
    inits of some drs.  But as the failed case, we shouldn't update the
    dr for simd_lane_access, it has the fixed-length storage mainly for
    the main loop, the update can make the access out of bound and access
    the unexpected element.

    gcc/ChangeLog:

            PR tree-optimization/102789
            * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
            update inits of simd_lane_access.

    (cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a)

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:

https://gcc.gnu.org/g:7cb3b868f702e63e53ee1880c6b8a61676144395

commit r11-9219-g7cb3b868f702e63e53ee1880c6b8a61676144395
Author: Kewen Lin <linkw@linux.ibm.com>
Date:   Mon Oct 25 21:05:02 2021 -0500

    vect: Don't update inits for simd_lane_access DRs [PR102789]

    As PR102789 shows, when vectorizer does some peelings for alignment
    in prologues, function vect_update_inits_of_drs would update the
    inits of some drs.  But as the failed case, we shouldn't update the
    dr for simd_lane_access, it has the fixed-length storage mainly for
    the main loop, the update can make the access out of bound and access
    the unexpected element.

    gcc/ChangeLog:

            PR tree-optimization/102789
            * tree-vect-loop-manip.c (vect_update_inits_of_drs): Do not
            update inits of simd_lane_access.

    (cherry picked from commit f3dbd3f36d55178d0a9e4431043cbc950524969a)

[Bug tree-optimization/102789] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

[linkw at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102789

Kewen Lin <linkw at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|REOPENED                    |RESOLVED

--- Comment #15 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for both replies!  Backported and bootstrapped on active branches
9/10/11.