https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
To reproduce, one can use e.g.
./gfortran -B ./ -fopenmp -O3 -flto -flto-partition=1to1 -fno-use-linker-plugin
async_target-2.f90 -fdump-tree-strlen -r -nostdlib -I
../x86_64-pc-linux-gnu/libgomp/ -B ../x86_64-pc-linux-gnu/libgomp/ -B
../x86_64-pc-linux-gnu/libgomp/.libs/ -v -save-temps
(if the test is copied into the gcc/ subdirectory of build dir).
The
vectp.52_27 = &MEM[(struct array01_real(kind=4) *)_7 clique 1 base
0].dtype.rank;
MEM <vector(2) signed char> [(signed char *)vectp.52_27 clique 1 base 0] = {
1, 3 };
the warning warns about has been created by SLP vectorization of
MEM[(struct array01_real(kind=4) *)_7 clique 1 base 0].dtype.rank = 1;
MEM[(struct array01_real(kind=4) *)_7 clique 1 base 0].dtype.type = 3;
It can be reproduced e.g. with -O3 on x86_64-linux:
struct T { char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p; };
struct S { long l; struct T t; };
void
foo (long l, struct S *p)
{
p->l = l;
p->t.a = 2;
p->t.b = 3;
p->t.c = 4;
p->t.d = 5;
p->t.e = 6;
p->t.f = 7;
p->t.g = 8;
p->t.h = 9;
p->t.i = 10;
p->t.j = 11;
p->t.k = 12;
p->t.l = 13;
p->t.m = 14;
p->t.n = 15;
p->t.o = 16;
}
Here slp2 pass changes:
+ vect_cst__20 = { 2, 3, 4, 5, 6, 7, 8, 9 };
p_2(D)->l = l_3(D);
- p_2(D)->t.a = 2;
- p_2(D)->t.b = 3;
- p_2(D)->t.c = 4;
- p_2(D)->t.d = 5;
- p_2(D)->t.e = 6;
- p_2(D)->t.f = 7;
- p_2(D)->t.g = 8;
- p_2(D)->t.h = 9;
+ vectp.4_21 = &p_2(D)->t.a;
+ MEM <vector(8) char> [(char *)vectp.4_21] = vect_cst__20;
This is valid GIMPLE IL, but like in PR92765, the warning code makes
assumptions that aren't valid in GIMPLE, after early opts where GCC for
__builtin_object_size (, [13]) purposes disables some optimization to ensure
the access paths are meaningful, later passes don't preserve it and for
ADDR_EXPR all that matters is the value,
i.e. what offset from the base needs to be added, what COMPONENT_REFs are there
or aren't doesn't mean anything.
