public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)
@ 2024-05-22 14:54 jukka.suomela at aalto dot fi
2024-05-22 14:55 ` [Bug c++/115192] " jukka.suomela at aalto dot fi
` (17 more replies)
0 siblings, 18 replies; 19+ messages in thread
From: jukka.suomela at aalto dot fi @ 2024-05-22 14:54 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars)
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
@ 2024-05-22 14:55 ` jukka.suomela at aalto dot fi
2024-05-22 15:29 ` [Bug c++/115192] [14/15 regression] " sjames at gcc dot gnu.org
` (16 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jukka.suomela at aalto dot fi @ 2024-05-22 14:55 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars)
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
2024-05-22 14:55 ` [Bug c++/115192] " jukka.suomela at aalto dot fi
@ 2024-05-22 15:29 ` sjames at gcc dot gnu.org
2024-05-22 15:37 ` [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
` (15 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-05-22 15:29 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
2024-05-22 14:55 ` [Bug c++/115192] " jukka.suomela at aalto dot fi
2024-05-22 15:29 ` [Bug c++/115192] [14/15 regression] " sjames at gcc dot gnu.org
@ 2024-05-22 15:37 ` jakub at gcc dot gnu.org
2024-05-22 17:02 ` jukka.suomela at aalto dot fi
` (14 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-22 15:37 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (2 preceding siblings ...)
2024-05-22 15:37 ` [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
@ 2024-05-22 17:02 ` jukka.suomela at aalto dot fi
2024-05-22 17:12 ` jakub at gcc dot gnu.org
` (13 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jukka.suomela at aalto dot fi @ 2024-05-22 17:02 UTC (permalink / raw)
To: gcc-bugs
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.)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r14-2117
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (3 preceding siblings ...)
2024-05-22 17:02 ` jukka.suomela at aalto dot fi
@ 2024-05-22 17:12 ` jakub at gcc dot gnu.org
2024-05-22 17:36 ` [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
` (12 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-22 17:12 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (4 preceding siblings ...)
2024-05-22 17:12 ` jakub at gcc dot gnu.org
@ 2024-05-22 17:36 ` sjames at gcc dot gnu.org
2024-05-23 7:05 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: sjames at gcc dot gnu.org @ 2024-05-22 17:36 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (5 preceding siblings ...)
2024-05-22 17:36 ` [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
@ 2024-05-23 7:05 ` rguenth at gcc dot gnu.org
2024-05-23 7:14 ` jakub at gcc dot gnu.org
` (10 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-23 7:05 UTC (permalink / raw)
To: gcc-bugs
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();
}
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (6 preceding siblings ...)
2024-05-23 7:05 ` rguenth at gcc dot gnu.org
@ 2024-05-23 7:14 ` jakub at gcc dot gnu.org
2024-05-23 8:09 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: jakub at gcc dot gnu.org @ 2024-05-23 7:14 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (7 preceding siblings ...)
2024-05-23 7:14 ` jakub at gcc dot gnu.org
@ 2024-05-23 8:09 ` rguenth at gcc dot gnu.org
2024-05-23 8:10 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-23 8:09 UTC (permalink / raw)
To: gcc-bugs
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>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (8 preceding siblings ...)
2024-05-23 8:09 ` rguenth at gcc dot gnu.org
@ 2024-05-23 8:10 ` rguenth at gcc dot gnu.org
2024-05-23 9:32 ` rsandifo at gcc dot gnu.org
` (7 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rguenth at gcc dot gnu.org @ 2024-05-23 8:10 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (9 preceding siblings ...)
2024-05-23 8:10 ` rguenth at gcc dot gnu.org
@ 2024-05-23 9:32 ` rsandifo at gcc dot gnu.org
2024-05-24 12:47 ` cvs-commit at gcc dot gnu.org
` (6 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2024-05-23 9:32 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14/15 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (10 preceding siblings ...)
2024-05-23 9:32 ` rsandifo at gcc dot gnu.org
@ 2024-05-24 12:47 ` cvs-commit at gcc dot gnu.org
2024-05-24 12:48 ` [Bug c++/115192] [11/12/13/14 " rsandifo at gcc dot gnu.org
` (5 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-24 12:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (11 preceding siblings ...)
2024-05-24 12:47 ` cvs-commit at gcc dot gnu.org
@ 2024-05-24 12:48 ` rsandifo at gcc dot gnu.org
2024-05-31 7:23 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2024-05-24 12:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13/14 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (12 preceding siblings ...)
2024-05-24 12:48 ` [Bug c++/115192] [11/12/13/14 " rsandifo at gcc dot gnu.org
@ 2024-05-31 7:23 ` cvs-commit at gcc dot gnu.org
2024-05-31 14:56 ` [Bug c++/115192] [11/12/13 " cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-31 7:23 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12/13 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (13 preceding siblings ...)
2024-05-31 7:23 ` cvs-commit at gcc dot gnu.org
@ 2024-05-31 14:56 ` cvs-commit at gcc dot gnu.org
2024-06-04 7:47 ` [Bug c++/115192] [11/12 " cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-05-31 14:56 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11/12 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (14 preceding siblings ...)
2024-05-31 14:56 ` [Bug c++/115192] [11/12/13 " cvs-commit at gcc dot gnu.org
@ 2024-06-04 7:47 ` cvs-commit at gcc dot gnu.org
2024-06-04 12:47 ` [Bug c++/115192] [11 " cvs-commit at gcc dot gnu.org
2024-06-04 12:48 ` rsandifo at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-06-04 7:47 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (15 preceding siblings ...)
2024-06-04 7:47 ` [Bug c++/115192] [11/12 " cvs-commit at gcc dot gnu.org
@ 2024-06-04 12:47 ` cvs-commit at gcc dot gnu.org
2024-06-04 12:48 ` rsandifo at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2024-06-04 12:47 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug c++/115192] [11 regression] -O3 miscompilation on x86-64 (loops with vectors and scalars) since r11-6380
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
` (16 preceding siblings ...)
2024-06-04 12:47 ` [Bug c++/115192] [11 " cvs-commit at gcc dot gnu.org
@ 2024-06-04 12:48 ` rsandifo at gcc dot gnu.org
17 siblings, 0 replies; 19+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2024-06-04 12:48 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2024-06-04 12:48 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-05-22 14:54 [Bug c++/115192] New: GCC 14.1.0 -O3 miscompilation on x86-64 (loops with vectors and scalars) jukka.suomela at aalto dot fi
2024-05-22 14:55 ` [Bug c++/115192] " jukka.suomela at aalto dot fi
2024-05-22 15:29 ` [Bug c++/115192] [14/15 regression] " sjames at gcc dot gnu.org
2024-05-22 15:37 ` [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
2024-05-22 17:02 ` jukka.suomela at aalto dot fi
2024-05-22 17:12 ` jakub at gcc dot gnu.org
2024-05-22 17:36 ` [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
2024-05-23 7:05 ` rguenth at gcc dot gnu.org
2024-05-23 7:14 ` jakub at gcc dot gnu.org
2024-05-23 8:09 ` rguenth at gcc dot gnu.org
2024-05-23 8:10 ` rguenth at gcc dot gnu.org
2024-05-23 9:32 ` rsandifo at gcc dot gnu.org
2024-05-24 12:47 ` cvs-commit at gcc dot gnu.org
2024-05-24 12:48 ` [Bug c++/115192] [11/12/13/14 " rsandifo at gcc dot gnu.org
2024-05-31 7:23 ` cvs-commit at gcc dot gnu.org
2024-05-31 14:56 ` [Bug c++/115192] [11/12/13 " cvs-commit at gcc dot gnu.org
2024-06-04 7:47 ` [Bug c++/115192] [11/12 " cvs-commit at gcc dot gnu.org
2024-06-04 12:47 ` [Bug c++/115192] [11 " cvs-commit at gcc dot gnu.org
2024-06-04 12:48 ` rsandifo at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).