[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #10 from Jakub Jelinek ---
Make that:
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;
p->t.p = 17;
}
and at -O3 slp2 doing:
+ vect_cst__21 = { 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 };
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;
- p_2(D)->t.i = 10;
- p_2(D)->t.j = 11;
- p_2(D)->t.k = 12;
- p_2(D)->t.l = 13;
- p_2(D)->t.m = 14;
- p_2(D)->t.n = 15;
- p_2(D)->t.o = 16;
- p_2(D)->t.p = 17;
+ vectp.4_22 = &p_2(D)->t.a;
+ MEM [(char *)vectp.4_22] = vect_cst__21;
pr92956.c: In function ‘foo’:
pr92956.c:8:10: warning: writing 16 bytes into a region of size 1
[-Wstringop-overflow=]
8 | p->t.a = 2;
| ~~~^~~
pr92956.c:1:17: note: at offset 0 to object ‘a’ with size 1 declared here
1 | struct T { char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p; };
| ^
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #9 from Jakub Jelinek ---
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 [(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 [(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.
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #8 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #7)
> testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing
> 2 bytes into a region of size 1 [-Wstringop-overflow=]
>34 | allocate (v1(N), v2(N))
> lto1: note: at offset 0 to object ‘rank’ with size 1 declared here
First, I want to note that there is no string (STRING_TYPE) around but only
numeric data types.
My feeling is that the following goes wrong, in -fdump-tree-omplower(-lineno),
one has:
D.4378 = .omp_data_i->v1;
D.4378->dtype.rank = 1;
D.4379 = .omp_data_i->v1;
D.4379->dtype.type = 3;
which later becomes (-fdump-dtree-strlen):
vectp.205_27 = & *_7.dtype.rank
MEM [(signed char *)vectp.205_27] = { 1, 3 };
See libgfortran/libgfortran.h for how the struct is organized; namely:
signed char rank;
signed char type;
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #7 from Tobias Burnus --- Created attachment 47512 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47512&action=edit -fdump-tree-strlen for both host run (async_target-2.f90.180t.strlen1, 1639 lines) and LTO nvptx run (async_target-2.o.180t.strlen1, 563 l.) (In reply to Thomas Schwinge from comment #6) > but I'll note that -- as we've seen in PR92952 -- it's actually useful in > other scenarios I think it can be useful in corner cases for Fortran for code written such that FE compiler cannot check it at compile time. With explicitly writing bounds, it can also be useful for a single TU, e.g. subroutine str(n) integer :: n character(len=n) :: str ! n = not known without call-argument propagation str(n:n+2) = 'abc' ! writes 2 bytes out of bounds Thus, you should consider to enable it for all languages - or at least Fortran in addition. > This problem persists, thus: I can confirm that the issue has been fixed for gfortran.dg/lto/pr87689_*, but not for libgomp.fortran/examples-4/async_target-2.f90 Using the same options as for async_target-2.f90, it also fails without actual offloading: gfortran-trunk -fopenmp -O3 -flto -flto-partition=1to1 -fno-use-linker-plugin testsuite/libgomp.fortran/examples-4/async_target-2.f90 -fdump-tree-strlen testsuite/libgomp.fortran/examples-4/async_target-2.f90: In function ‘vec_mult_._omp_fn.2’: testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2 bytes into a region of size 1 [-Wstringop-overflow=] 34 | allocate (v1(N), v2(N)) | lto1: note: at offset 0 to object ‘rank’ with size 1 declared here testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2 bytes into a region of size 1 [-Wstringop-overflow=] lto1: note: at offset 0 to object ‘rank’ with size 1 declared here * * * With offloading, it fails for: 10.0.0/accel/nvptx-none/lto1 -fdump-tree-strlen -quiet -dumpbase async_target-2.o -m64 -mgomp -auxbase async_target-2 -O3 -version -fno-openacc -fno-pie -foffload-abi=lp64 -fopenmp @/tmp/ccarNfXs -o async_target-2.s * * * I have now attached both -fdump-tree-strlen
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 Thomas Schwinge changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-12-17 Resolution|DUPLICATE |--- Ever confirmed|0 |1 --- Comment #6 from Thomas Schwinge --- (In reply to Martin Sebor from comment #2) > -Wstringop-overflow is a C-family only option that shouldn't be enabled for > Fortran. It took some effort to make it work that way (see pr80545 for the > background) and there's no test for it so either the logic put in there > still isn't correct or something has regressed. I don't have time right now to read up the history/rationale behind that (enabling a generic? middle-end warning only for certain source languages), but I'll note that -- as we've seen in PR92952 -- it's actually useful in other scenarios, too? (And if only to make the analysis' code more robust.) (In reply to Martin Sebor from comment #5) > Thanks! Yes, the code made the incorrect assumption that array indices were > zero-based. I just committed r279445 with a fix so I'm going to assume it > takes care of these warnings as well as will resolve this as a duplicate. This problem persists, thus: > *** This bug has been marked as a duplicate of bug 92952 *** Re-opened.
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Martin Sebor --- Thanks! Yes, the code made the incorrect assumption that array indices were zero-based. I just committed r279445 with a fix so I'm going to assume it takes care of these warnings as well as will resolve this as a duplicate. *** This bug has been marked as a duplicate of bug 92952 ***
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #4 from Tobias Burnus ---
Created attachment 47508
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47508&action=edit
-fdump-tree-strlen dump of gcc/testsuite/gfortran.dg/lto/pr87689_*.f
As requested, the output of:
$ gfortran-trunk -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin
gfortran.dg/lto/pr87689_* -fdump-tree-strlen
$ head -n 20 pr87689_0.f.180t.strlen1 pr87689_1.f.180t.strlen1 >
strlen.txt
I think the following causes the confusion:
character(kind=1)[1:1] & restrict c,
…
_7 = (*c_15(D))[1]{lb: 1 sz: 1};
'c' is a string of length 1 but the lower bound is also 1, hence "c[1]"
accesses the first element of the string.
I wonder whether you case assumes that the lower bound is always 0? – On the
other hand, this issue only appears with inlining (and the specified LTO
options), w/o there is no warning.
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #3 from Tobias Burnus --- (In reply to Martin Sebor from comment #2) > -Wstringop-overflow is a C-family only option that shouldn't be enabled for > Fortran. It took some effort to make it work that way […] I wouldn't be > surprised if the problem was still unresolved in LTO builds Well, this uses LTO – but only behind the scenes. When doing offloading (via OpenACC or OpenMP ["omp target"]), the blocks which are to be run on the device will be processes by a lto1 compiler for the device target (amdgcn, nvptx), see https://gcc.gnu.org/wiki/Offloading > I don't see this test in my builds or on gcc-testresults and compiling it > by hand gives the error below. […] > Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No > such file or directory I think in order to reproduce Thomas' problem, I fear you need to configure the compiler for actual offloading. (But see below.) Still, I do not understand the error message. This file is part of libgomp and installed along the compiler; in my case, it is in $INSTALL/lib64/gcc/x86_64-pc-linux-gnu/10.0.0/finclude/ and should be found automatically when calling 'gfortran'. * * * Regarding a test case, I actually stumbled over a test case this afternoon which fails without offloading. (There are 22 PASS and this one FAIL.) — I don't know whether it is your commit, but the message looks very similar. In any case: FAIL: gfortran.dg/lto/pr87689 f_lto_pr87689_0.o-f_lto_pr87689_1.o link, -O2 -flto -flto-partition=1to1 -fno-use-linker-plugin Which fails with: In function 'MAIN__', inlined from 'main' at gcc/testsuite/gfortran.dg/lto/pr87689_0.f:13:0: gcc/testsuite/gfortran.dg/lto/pr87689_0.f:10: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] gcc/testsuite/gfortran.dg/lto/pr87689_0.f: In function 'main': gcc/testsuite/gfortran.dg/lto/pr87689_0.f:7:22: note: at offset 1 to object 'c' with size 1 declared here The message is also bogus as one writes a single character to to a len=1 string.
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #2 from Martin Sebor --- -Wstringop-overflow is a C-family only option that shouldn't be enabled for Fortran. It took some effort to make it work that way (see pr80545 for the background) and there's no test for it so either the logic put in there still isn't correct or something has regressed. I wouldn't be surprised if the problem was still unresolved in LTO builds (e.g., pr92952) but this doesn't look like like an LTO test. I don't see this test in my builds or on gcc-testresults and compiling it by hand gives the error below. What do I need to do to build it? /ssd/src/gcc/svn/libgomp/testsuite/libgomp.fortran/examples-4/async_target-2.f90:25:7: 25 | use omp_lib, only: omp_is_initial_device | 1 Fatal Error: Cannot open module file ‘omp_lib.mod’ for reading at (1): No such file or directory compilation terminated. Can you include the strlen dump for the test (-fdump-tree-strlen)?
[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #1 from Thomas Schwinge --- (In reply to myself from comment #0) > regression in (all?) OpenMP 'target' offloading compilation testing, for > example with 64-bit nvptx: ;-) This "all" here means (presumably?) all different offload target configurations, not "all test cases". (I'm seeing this just for 'libgomp.fortran/examples-4/async_target-2.f90'.) > Similarly for 32-bit Intel MIC (emulated) offloading.
