[Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)

[Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)

[jukka.suomela at aalto dot fi]

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

            Bug ID: 115192
           Summary: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with
                    vectors and scalars)
           Product: gcc
           Version: 14.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jukka.suomela at aalto dot fi
  Target Milestone: ---

Created attachment 58268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58268&action=edit
Preprocessed source code

It seems that GCC 14.1.0 with -O3 mis-compiles the attached code on x86-64. The
key element seems to be loops that involve both arrays of vector types and
arrays of scalar types.

This is the expected output:

$ g++-14 -Wall -Wextra -O2 test.cc -o test && ./test
0.000000 0.000000
3.000000 3.000000
9.000000 9.000000

This is the unexpected output that we got with -O3:

$ g++-14 -Wall -Wextra -O3 test.cc -o test && ./test
0.000000 0.000000
3.000000 3.000000
6.000000 6.000000

I have attached the preprocessed source code produced by the following command,
and I will attach also the full compiler output that I got:

g++-14 -v -save-temps -Wall -Wextra -O3 test.cc -o test

Compiler: GNU C++17 (Homebrew GCC 14.1.0) version 14.1.0
(x86_64-apple-darwin21), compiled by GNU C version 14.1.0, GMP version 6.3.0,
MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.26-GMP, Target:
x86_64-apple-darwin21.6.0.

This is GCC on Intel-macOS from Homebrew, but we originally noticed the problem
in Intel-Linux, so it doesn't seem to be specific to macOS or Homebrew.
However, I wasn't able to reproduce the bug on Apple M3, so it might be
specific to x86-64.

[Bug c++/115192] GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)

[jukka.suomela at aalto dot fi]

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

--- Comment #1 from Jukka Suomela <jukka.suomela at aalto dot fi> ---
Created attachment 58269
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58269&action=edit
Compiler output

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars)

[sjames at gcc dot gnu.org]

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

--- Comment #2 from Sam James <sjames at gcc dot gnu.org> ---
Created attachment 58270
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58270&action=edit
bisect-me.cxx

I'll bisect with attached.

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2024-05-22
   Target Milestone|---                         |14.2
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org
           Priority|P3                          |P2
             Status|UNCONFIRMED                 |NEW
            Summary|[14/15 regression] -O3      |[14/15 regression] -O3
                   |miscompilation on x86-64    |miscompilation on x86-64
                   |(loops with vectors and     |(loops with vectors and
                   |scalars)                    |scalars) since r14-2117

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Since r14-2117-gdd86a5a69cbda40cf76388a65d3317c91cb2b501

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117

[jukka.suomela at aalto dot fi]

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

--- Comment #4 from Jukka Suomela <jukka.suomela at aalto dot fi> ---
Created attachment 58271
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58271&action=edit
Another example, miscompiles with GCC 11 (-O3 -march=skylake)

Here is a minor variant of the theme. This variant seems to fail already on GCC
11 if I compile with -O3 -march=skylake.

Expected:

$ g++-11 -Wall -Wextra test.cc -O2 -march=skylake -o test && ./test
0.000000 0.000000
11.000000 22.000000
22.000000 44.000000

Unexpected:

$ g++-11 -Wall -Wextra test.cc -O3 -march=skylake -o test && ./test
0.000000 0.000000
11.000000 22.000000
11.000000 22.000000

This was with g++-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0 on x86_64-linux-gnu.
In godbolt.org GCC 11.1 seemed to be the first version where this behavior
started.

(Apologies if this should be a separate bug report. I posted this here, as I
suspect the bugs might be related.)

[Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rsandifo at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The #c4 testcase changed behavior with
r11-6380-g9fa5b473b5b8e289b6542adfd5cfaddfb3036048

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[14/15 regression] -O3      |[11/12/13/14/15 regression]
                   |miscompilation on x86-64    |-O3 miscompilation on
                   |(loops with vectors and     |x86-64 (loops with vectors
                   |scalars) since r14-2117     |and scalars) since r11-6380

--- Comment #6 from Sam James <sjames at gcc dot gnu.org> ---
Retitling then so it doesn't get lost. Can always split if needed.

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'm looking into the first issue.  Interesting fact:

> /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec -fno-tree-slp-vectorize --param vect-epilogues-nomask=0
t.C:7:21: optimized: loop vectorized using 16 byte vectors
t.C:7:21: optimized:  loop versioned for vectorization because of possible
aliasing
rguenther@localhost:/tmp> ./a.out
> /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec -fno-tree-slp-vectorize --param vect-epilogues-nomask=1
t.C:7:21: optimized: loop vectorized using 16 byte vectors
t.C:7:21: optimized:  loop versioned for vectorization because of possible
aliasing
t.C:7:21: optimized: loop vectorized using 8 byte vectors
rguenther@localhost:/tmp> ./a.out 
Aborted (core dumped)

so avoiding the vectorized epilog fixes this (I've also placed #pragma GCC
novector on the loop in main and noipa on foo).

C testcase:

typedef float float4_t __attribute__((vector_size(4 * sizeof(float))));

void __attribute__((noipa))
foo(int n, const float *d, float4_t * __restrict a)
{
  for (int y = 1; y < n; y++)
    for (int c = 0; c < 2; c++)
      a[y * n][c] = d[y * n] + a[(y - 1) * n][c];
}

int main()
{ 
  const int n = 3;
  float d[n*n];
  float4_t a[n*n];
#pragma GCC novector
  for (int i = 0; i < n * n; ++i)
    d[i] = i;
  foo(n, d, a);
  if (a[6][1] != 9)
    __builtin_abort();
}

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> int main()
> { 
>   const int n = 3;
>   float d[n*n];
>   float4_t a[n*n];

I'd recommend using #define n 3 or enum { n = 3 }; instead of const int n = 3;
so that the arrays aren't unnecessary VLAs.

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> I'm looking into the first issue.  Interesting fact:
> 
> > /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec -fno-tree-slp-vectorize --param vect-epilogues-nomask=0
> t.C:7:21: optimized: loop vectorized using 16 byte vectors
> t.C:7:21: optimized:  loop versioned for vectorization because of possible
> aliasing
> rguenther@localhost:/tmp> ./a.out
> > /space/rguenther/install/gcc-14.1/bin/g++ t.C -O3 -fopt-info-vec -fno-tree-slp-vectorize --param vect-epilogues-nomask=1
> t.C:7:21: optimized: loop vectorized using 16 byte vectors
> t.C:7:21: optimized:  loop versioned for vectorization because of possible
> aliasing
> t.C:7:21: optimized: loop vectorized using 8 byte vectors
> rguenther@localhost:/tmp> ./a.out 
> Aborted (core dumped)
> 
> so avoiding the vectorized epilog fixes this (I've also placed #pragma GCC
> novector on the loop in main and noipa on foo).

Actually with -fno-vect-cost-model even --param vect-epilogues-nomask=0 fails.
Since we are vectorizing

  for (int y = 1; y < n; y++)
    {
      a[y * n][0] = d[y * n] + a[(y - 1) * n][0];
      a[y * n][1] = d[y * n] + a[(y - 1) * n][1];
    }

with a VF of two this is a failure to identify the dependence between
the iterations, so possibly related to r11-6380 as well.

(compute_affine_dependence
  ref_a: BIT_FIELD_REF <*_37, 32, 0>, stmt_a: _38 = BIT_FIELD_REF <*_37, 32,
0>;  ref_b: BIT_FIELD_REF <*_40, 32, 0>, stmt_b: BIT_FIELD_REF <*_40, 32, 0> =
_41;
) -> dependence analysis failed

Creating dr for BIT_FIELD_REF <*_37, 32, 0>
analyze_innermost: success.
        base_address: a_23(D)
        offset from base address: 0
        constant offset from base address: 0
        step: (ssizetype) ((long unsigned int) n_20(D) * 16)
        base alignment: 16
        base misalignment: 0
        offset alignment: 128
        step alignment: 16
        base_object: BIT_FIELD_REF <*_37, 32, 0>

Creating dr for BIT_FIELD_REF <*_40, 32, 0>
analyze_innermost: success.
        base_address: (float4_t *) a_23(D) + (sizetype) n_20(D) * 16
        offset from base address: 0
        constant offset from base address: 0
        step: (ssizetype) ((long unsigned int) n_20(D) * 16)
        base alignment: 16
        base misalignment: 0
        offset alignment: 128
        step alignment: 16
        base_object: BIT_FIELD_REF <*_40, 32, 0>

and for reference

Creating dr for BIT_FIELD_REF <*_37, 32, 32>
analyze_innermost: success.
        base_address: a_23(D)
        offset from base address: 0
        constant offset from base address: 4
        step: (ssizetype) ((long unsigned int) n_20(D) * 16)
        base alignment: 16
        base misalignment: 0
        offset alignment: 128
        step alignment: 16
        base_object: BIT_FIELD_REF <*_37, 32, 32>

that looks sensible.  And 'a' is indeed properly aligned.

t.c:6:21: note:   recording new base alignment for d_22(D) + (sizetype) n_20(D)
* 4
  alignment:    4
  misalignment: 0
  based on:     _32 = *_31;
t.c:6:21: note:   recording new base alignment for a_23(D)
  alignment:    16
  misalignment: 0
  based on:     _38 = BIT_FIELD_REF <*_37, 32, 0>;
t.c:6:21: note:   recording new base alignment for (float4_t *) a_23(D) +
(sizetype) n_20(D) * 16
  alignment:    16
  misalignment: 0
  based on:     BIT_FIELD_REF <*_40, 32, 0> = _41;
t.c:6:21: note:   vect_compute_data_ref_alignment:
t.c:6:21: missed:   step doesn't divide the vector alignment.
t.c:6:21: missed:   Unknown alignment for access: *_31
t.c:6:21: note:   vect_compute_data_ref_alignment:
t.c:6:21: missed:   Unknown alignment for access: BIT_FIELD_REF <*_37, 32, 0>
t.c:6:21: note:   vect_compute_data_ref_alignment:
t.c:6:21: missed:   Unknown alignment for access: BIT_FIELD_REF <*_40, 32, 0>

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|rguenth at gcc dot gnu.org         |unassigned at gcc dot gnu.org

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[rsandifo at gcc dot gnu.org]

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

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rsandifo at gcc dot gnu.org

[Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Richard Sandiford <rsandifo@gcc.gnu.org>:

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

commit r15-820-ga0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Fri May 24 13:47:21 2024 +0100

    vect: Fix access size alignment assumption [PR115192]

    create_intersect_range_checks checks whether two access ranges
    a and b are alias-free using something equivalent to:

      end_a <= start_b || end_b <= start_a

    It has two ways of doing this: a "vanilla" way that calculates
    the exact exclusive end pointers, and another way that uses the
    last inclusive aligned pointers (and changes the comparisons
    accordingly).  The comment for the latter is:

          /* Calculate the minimum alignment shared by all four pointers,
             then arrange for this alignment to be subtracted from the
             exclusive maximum values to get inclusive maximum values.
             This "- min_align" is cumulative with a "+ access_size"
             in the calculation of the maximum values.  In the best
             (and common) case, the two cancel each other out, leaving
             us with an inclusive bound based only on seg_len.  In the
             worst case we're simply adding a smaller number than before.

    The problem is that the associated code implicitly assumed that the
    access size was a multiple of the pointer alignment, and so the
    alignment could be carried over to the exclusive end pointer.

    The testcase started failing after g:9fa5b473b5b8e289b6542
    because that commit improved the alignment information for
    the accesses.

    gcc/
            PR tree-optimization/115192
            * tree-data-ref.cc (create_intersect_range_checks): Take the
            alignment of the access sizes into account.

    gcc/testsuite/
            PR tree-optimization/115192
            * gcc.dg/vect/pr115192.c: New test.

[Bug c++/115192] [11/12/13/14 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[rsandifo at gcc dot gnu.org]

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

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12/13/14/15 regression] |[11/12/13/14 regression]
                   |-O3 miscompilation on       |-O3 miscompilation on
                   |x86-64 (loops with vectors  |x86-64 (loops with vectors
                   |and scalars) since r11-6380 |and scalars) since r11-6380

--- Comment #11 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
Fixed on trunk, will backport if there is no reported fallout.

[Bug c++/115192] [11/12/13/14 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-14 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:36575f5fe491d86b6851ff3f47cbfb7dad0fc8ae

commit r14-10263-g36575f5fe491d86b6851ff3f47cbfb7dad0fc8ae
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Fri May 31 08:22:55 2024 +0100

    vect: Fix access size alignment assumption [PR115192]

    create_intersect_range_checks checks whether two access ranges
    a and b are alias-free using something equivalent to:

      end_a <= start_b || end_b <= start_a

    It has two ways of doing this: a "vanilla" way that calculates
    the exact exclusive end pointers, and another way that uses the
    last inclusive aligned pointers (and changes the comparisons
    accordingly).  The comment for the latter is:

          /* Calculate the minimum alignment shared by all four pointers,
             then arrange for this alignment to be subtracted from the
             exclusive maximum values to get inclusive maximum values.
             This "- min_align" is cumulative with a "+ access_size"
             in the calculation of the maximum values.  In the best
             (and common) case, the two cancel each other out, leaving
             us with an inclusive bound based only on seg_len.  In the
             worst case we're simply adding a smaller number than before.

    The problem is that the associated code implicitly assumed that the
    access size was a multiple of the pointer alignment, and so the
    alignment could be carried over to the exclusive end pointer.

    The testcase started failing after g:9fa5b473b5b8e289b6542
    because that commit improved the alignment information for
    the accesses.

    gcc/
            PR tree-optimization/115192
            * tree-data-ref.cc (create_intersect_range_checks): Take the
            alignment of the access sizes into account.

    gcc/testsuite/
            PR tree-optimization/115192
            * gcc.dg/vect/pr115192.c: New test.

    (cherry picked from commit a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba)

[Bug c++/115192] [11/12/13 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:0836216693749f3b0b383d015bd36c004754f1da

commit r13-8812-g0836216693749f3b0b383d015bd36c004754f1da
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Fri May 31 15:56:04 2024 +0100

    vect: Fix access size alignment assumption [PR115192]

    create_intersect_range_checks checks whether two access ranges
    a and b are alias-free using something equivalent to:

      end_a <= start_b || end_b <= start_a

    It has two ways of doing this: a "vanilla" way that calculates
    the exact exclusive end pointers, and another way that uses the
    last inclusive aligned pointers (and changes the comparisons
    accordingly).  The comment for the latter is:

          /* Calculate the minimum alignment shared by all four pointers,
             then arrange for this alignment to be subtracted from the
             exclusive maximum values to get inclusive maximum values.
             This "- min_align" is cumulative with a "+ access_size"
             in the calculation of the maximum values.  In the best
             (and common) case, the two cancel each other out, leaving
             us with an inclusive bound based only on seg_len.  In the
             worst case we're simply adding a smaller number than before.

    The problem is that the associated code implicitly assumed that the
    access size was a multiple of the pointer alignment, and so the
    alignment could be carried over to the exclusive end pointer.

    The testcase started failing after g:9fa5b473b5b8e289b6542
    because that commit improved the alignment information for
    the accesses.

    gcc/
            PR tree-optimization/115192
            * tree-data-ref.cc (create_intersect_range_checks): Take the
            alignment of the access sizes into account.

    gcc/testsuite/
            PR tree-optimization/115192
            * gcc.dg/vect/pr115192.c: New test.

    (cherry picked from commit a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba)

[Bug c++/115192] [11/12 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

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

commit r12-10488-gf510e59db482456160b8a63dc083c78b0c1f6c09
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Jun 4 08:47:47 2024 +0100

    vect: Fix access size alignment assumption [PR115192]

    create_intersect_range_checks checks whether two access ranges
    a and b are alias-free using something equivalent to:

      end_a <= start_b || end_b <= start_a

    It has two ways of doing this: a "vanilla" way that calculates
    the exact exclusive end pointers, and another way that uses the
    last inclusive aligned pointers (and changes the comparisons
    accordingly).  The comment for the latter is:

          /* Calculate the minimum alignment shared by all four pointers,
             then arrange for this alignment to be subtracted from the
             exclusive maximum values to get inclusive maximum values.
             This "- min_align" is cumulative with a "+ access_size"
             in the calculation of the maximum values.  In the best
             (and common) case, the two cancel each other out, leaving
             us with an inclusive bound based only on seg_len.  In the
             worst case we're simply adding a smaller number than before.

    The problem is that the associated code implicitly assumed that the
    access size was a multiple of the pointer alignment, and so the
    alignment could be carried over to the exclusive end pointer.

    The testcase started failing after g:9fa5b473b5b8e289b6542
    because that commit improved the alignment information for
    the accesses.

    gcc/
            PR tree-optimization/115192
            * tree-data-ref.cc (create_intersect_range_checks): Take the
            alignment of the access sizes into account.

    gcc/testsuite/
            PR tree-optimization/115192
            * gcc.dg/vect/pr115192.c: New test.

    (cherry picked from commit a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba)

[Bug c++/115192] [11 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Richard Sandiford
<rsandifo@gcc.gnu.org>:

https://gcc.gnu.org/g:741ea10418987ac02eb8e680f2946a6e5928eb23

commit r11-11465-g741ea10418987ac02eb8e680f2946a6e5928eb23
Author: Richard Sandiford <richard.sandiford@arm.com>
Date:   Tue Jun 4 13:47:34 2024 +0100

    vect: Fix access size alignment assumption [PR115192]

    create_intersect_range_checks checks whether two access ranges
    a and b are alias-free using something equivalent to:

      end_a <= start_b || end_b <= start_a

    It has two ways of doing this: a "vanilla" way that calculates
    the exact exclusive end pointers, and another way that uses the
    last inclusive aligned pointers (and changes the comparisons
    accordingly).  The comment for the latter is:

          /* Calculate the minimum alignment shared by all four pointers,
             then arrange for this alignment to be subtracted from the
             exclusive maximum values to get inclusive maximum values.
             This "- min_align" is cumulative with a "+ access_size"
             in the calculation of the maximum values.  In the best
             (and common) case, the two cancel each other out, leaving
             us with an inclusive bound based only on seg_len.  In the
             worst case we're simply adding a smaller number than before.

    The problem is that the associated code implicitly assumed that the
    access size was a multiple of the pointer alignment, and so the
    alignment could be carried over to the exclusive end pointer.

    The testcase started failing after g:9fa5b473b5b8e289b6542
    because that commit improved the alignment information for
    the accesses.

    gcc/
            PR tree-optimization/115192
            * tree-data-ref.c (create_intersect_range_checks): Take the
            alignment of the access sizes into account.

    gcc/testsuite/
            PR tree-optimization/115192
            * gcc.dg/vect/pr115192.c: New test.

    (cherry picked from commit a0fe4fb1c8d7804515845dd5d2a814b3c7a1ccba)

[Bug c++/115192] [11 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380

[rsandifo at gcc dot gnu.org]

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

Richard Sandiford <rsandifo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |11.4.1
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #16 from Richard Sandiford <rsandifo at gcc dot gnu.org> ---
Fixed.