[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 Tobias Burnus changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #17 from Tobias Burnus --- (In reply to Martin Sebor from comment #16) > I would expect r280041 to suppress the warnings but I haven't tested it. > Thomas or Tobias, can one of you please verify they are gone and resolve the > bug if appropriate? I can confirm that without a slightly older GCC I still see the issue (of comment 0, with nvptx) – and after "svn up" + build, the issue is gone. Hence: FIXED. Thanks for the patch!
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #16 from Martin Sebor --- I would expect r280041 to suppress the warnings but I haven't tested it. Thomas or Tobias, can one of you please verify they are gone and resolve the bug if appropriate?
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #15 from Martin Sebor --- Author: msebor Date: Thu Jan 9 11:59:41 2020 New Revision: 280041 URL: https://gcc.gnu.org/viewcvs?rev=280041=gcc=rev Log: PR middle-end/93200 - spurious -Wstringop-overflow due to assignment vectorization to multiple members PR fortran/92956 - 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning gcc/testsuite/ChangeLog: PR middle-end/93200 * gcc.dg/Wstringop-overflow-30.c: New test. gcc/ChangeLog: PR middle-end/93200 PR fortran/92956 * builtins.c (compute_objsize): Avoid handling MEM_REFs of vector type. Added: trunk/gcc/testsuite/gcc.dg/Wstringop-overflow-30.c Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 Richard Biener changed: What|Removed |Added Version|unknown |10.0 Target Milestone|--- |10.0
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #14 from Martin Sebor ---
(In reply to Tobias Burnus from comment #12)
The warnings have been enabled by default since _FORTIFY_SOURCE (and Builtin
Size Checking) was introduced. Given their severity I don't think we want
consider changing the default setting. Splitting up the warning into two
wouldn't be a good solution, or even a good workaround, because there's no
obvious difference between the source code that is prone to the false positives
and code that isn't (as far as users can tell, the code looks the same).
LTO is a problem in the sense that it enables a C-only warning for FORTRAN
code. But a similar problem also affects C if the warning is disabled via
#pragma GCC diagnostic (see below). Incidentally, the converse problem (false
negatives) affects -Warray-bounds: out-of-bounds indices aren't diagnosed even
when explicitly requested (to see that, replace char with int below).
We need to come up with a solution to avoid diagnosing code that's synthesized
by GCC itself (without introducing false negatives), and we need to get the
warning suppression working reliably. With and without LTO. I'm planning to
look into the #pragma problem in January but I'm not sure coming up with a
solution for the the other problem is feasible in GCC 10.
$ cat a.c && gcc -O2 -flto -c -o a1.o a.c && gcc -DMAIN -O2 -flto -c -o a2.o
a.c && gcc -O2 -flto a1.o a2.o -o a.out
#pragma GCC diagnostic ignored "-Wstringop-overflow"
typedef char T;
#if MAIN
T i;
void f (T*);
int main (void)
{
f ();
return i;
}
#else
void f (T *p)
{
p[3] = 0;
}
#endif
In function ‘f’,
inlined from ‘main’ at a.c:13:3:
a.c:21:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
21 | p[3] = 0;
|^
a.c: In function ‘main’:
a.c:7:3: note: at offset 3 to object ‘i’ with size 1 declared here
7 | T i;
| ^
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956
--- Comment #13 from Martin Sebor ---
(In reply to Jakub Jelinek from comment #9)
Thanks for the nice test case! The assumptions the warning makes aren't
accidental: it tries to detect bugs that would otherwise go undetected, and it
relies on the fact that the IL, although ambiguous (as in: matching both valid
code injected by GCC itself, as well as accidental bugs introduced by careless
programmers), corresponds to the source code more often than not. It's a
trade-off between false negatives and false positives, with the balance
shifting each time a new transformation is added that breaks the assumption.
The only way to do better is to make the IL reflect the distinction between the
two classes of uses).
The GIMPLE in the test case in comment #10 that causes the warning is this:
p_2(D)->l = l_3(D);
vectp.5_21 = _2(D)->t.a;
MEM [(char *)vectp.5_21] = { 2, 3, 4, 5, 6, 7, 8, 9 };
and the warning sees that vectp.5_21 is just a pointer to p->t.a. If, for
example, the IL instead looked like this:
p_2(D)->l = l_3(D);
MEM[(Vec8 *)p_2(D) + 8B] = { 2, 3, 4, 5, 6, 7, 8, 9 };
vectp.10_14 = _2(D)->t.i;
the warning (as it is today) wouldn't trigger (Vec8 is a typedef for
__attribute__ ((vector_size (8))) char) because it doesn't know how to convert
offsets into structs into members (but that's just a limitation that I hope to
remove). But even this IL is still ambiguous because it corresponds to this
assignment:
*((Vec8*)>t.a) = (Vec8){ 2, 3, 4, 5, 6, 7, 8, 9 };
Here the overflow is intended to be detected but won't be. Worse, a trivial
change to the code like so results in the former IL, bringing the warning back:
*((__attribute__ ((vector_size (8))) char*)>t.a) = (__attribute__
((vector_size (8))) char){ 2, 3, 4, 5, 6, 7, 8, 9 };
To avoid this problem we just need to "encode" the cast in the MEM_REF
destination argument (or maybe the type of the offset) used by optimizers in a
way that doesn't correspond to a valid source code construct. Or, more
generally, just use some unused bit in the MEM_REF representation to
distinguish the two cases. I'm not an expert on GIMPLE so I don't have a good
sense of what would work or work best, but if the idea is sound I'll try to
look into it for GCC 11.
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #12 from Tobias Burnus --- (In reply to Martin Sebor from comment #11) > Because like all flow-based warnings, -Wstringop-overflow has a non-zero rate > of false positives I think false positive is okay fine, but the question is whether the option should then be enabled by default. – That's independent whether it is C, C++ or Fortran. I think someone who use several -W… options is fine with false positives, but those who use only default options should not see bogus results. Or split this in two parts – one for those parts before the problematic GIMPLE optimizations – enabled by default (at least for C/C++). And another option for warnings after GIMPLE "messed up" which the user has to specify explicitly (might also be implied by -Wextra or maybe even -Wall). > LTO builds are known to have issues with interpreting command line options, My feeling is that this more a problem of GIMPLE doing optimization that about LTO and command-line options. — At least comment 11 and PR 92765 look like C code to me. > If this warning is useful even in FORTRAN despite the non-zero false > positive rate […] the option can be made generic I think it has some use – a bit more limited as it is not as easy as in C to run into such string bugs, but it can detect some issues also in Fortran code. – As in C but due to the limited benefit even more so: it as a whole – or at least those parts after the GIMPLE optimization – should only be enabled by a -W flag (might well be implied, e.g., by -Wextra).
[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92956 --- Comment #11 from Martin Sebor --- Here's some history. When -Wstringop-overflow was introduced it only detected overflow in calls to C functions like strcpy or memcpy that aren't normally seen in FORTRAN programs. It provided a means of controlling warnings issued by _FORTIFY_SOURCE for overflowing calls to string functions like strcpy. But _FORTIFY_SOURCE misses many buffer overflows and so the warning was enhanced to detect some of those. Because like all flow-based warnings, -Wstringop-overflow has a non-zero rate of false positives, it was meant to be enabled only for the languages where such calls were normally made directly. It was only recently that the warning has also started detecting overflow by assignments. That was done partly because GCC itself transforms calls to library functions like strcpy or memcpy to direct assignments via MEM_REF, which previously prevented buffer overflows by those assignments from being detected. LTO builds are known to have issues with interpreting command line options, including warnings (e.g., merging options used to compile different translation units when functions defined in those units are inlined into one another). I don't know all the details here but I do know it's a topic of ongoing discussion. One solution/workaround I've heard suggested is specifying the expected options when linking. Does passing -Wno-stringop-overflow when linking (with LTO) suppress the warnings? If this warning is useful even in FORTRAN despite the non-zero false positive rate, or maybe because of it with LTO, the option can be made generic so the false positives can be suppressed using #pragma GCC diagnostic or on the command line when compiling. (I should mention that even #pragma GCC diagnostic doesn't work completely reliably with optimization, and I have no idea how or if it works with LTO. It's something I'm yet to look into.)
