[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
Martin Sebor changed:
What|Removed |Added
Last reconfirmed||2015-11-11
CC||msebor at gcc dot gnu.org
--- Comment #6 from Martin Sebor ---
6.0.0 2015 issues the following slightly different warnings which disappear
when the increment of r in the first loop is made undonditional. Since the
condition should always be true (r can never be zero), the warning on that line
seems pointless (though not necessarily incorrect -- GCC is right to assume
there's no overflow).
I don't really know what to make of this so I'm leaving it UNCONFIRMED and for
someone else to look into in more depth.
$ cat u.c && /home/msebor/build/gcc-trunk/gcc/xgcc -B
/home/msebor/build/gcc-trunk/gcc -O2 -S -Wstrict-overflow=3 -o/dev/null
-std=c99 u.c
void h(int *s);
void f(int n, int s)
{
int r = 1;
for (int i = 1; i < n; i++)
if (r)
r++;
if (r * s >= s + 3) // warning here
for (int j = 0; j < r; j++)
h(&s);
}
u.c: In function ‘f’:
u.c:7:20: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
if (r)
^
u.c:10:17: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
for (int j = 0; j < r; j++)
^
u.c:10:17: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217 Andrew Pinski changed: What|Removed |Added Known to fail||7.5.0 Keywords||needs-bisection --- Comment #7 from Andrew Pinski --- The diagnostic seems to be gone in GCC 8+.
[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- Fixed with r8-395-g02c6414935bddf1c.
[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez --- (In reply to Michael Veksler from comment #1) > (Strange that this hasn't been confirmed for over a year!) Too many bug reports and too few developers...
[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217 --- Comment #4 from Manuel López-Ibáñez --- (In reply to Michael Veksler from comment #2) > > This make no sense at all and significantly lowers the usability of > -Wstrict-overflow=3. Either VRP or constant-propagation must have realized > that > overflow is impossible, or does VRP come into play only after the warning is > emitted? Or maybe VRP can't do it because such reasoning requires induction? I don't have an answer to these questions, but probably you can find out using the -fdump-tree-all-all-lineno flag.
[Bug middle-end/55217] False -Wstrict-overflow warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #5 from Michael Veksler ---
Running the delta.c example with -fdump-tree-all-all-lineno produces
delta.c.125t.vrp2.
For some reason, stop_9 (which is the first stop_.* in the file) is initialized
with stop_9 = barD.1593 (), but it should have been initialized with 0.
=
# i_17 = PHI <[delta.c : 5:36] i_10(4), [delta.c : 5:14] 10(2)>
# .MEM_18 = PHI <.MEM_8(4), .MEM_4(D)(2)>
[delta.c : 6:13] # .MEM_8 = VDEF <.MEM_18>
# USE = nonlocal
# CLB = nonlocal
stop_9 = barD.1593 (); <== Weird reorder
[delta.c : 5:36] i_10 = i_17 + -1;
[delta.c : 5:22] _5 = i_10 >= 0;
[delta.c : 5:29] _6 = stop_9 == 0;
[delta.c : 5:26] _7 = _6 & _5;
[delta.c : 5:5] if (_7 != 0)
goto ;
else
goto ;
==
This seems wrong because the first time stop == 0 is checked at the source is:
int stop= 0;
for (int i=10 ; i>=0 && !stop; --i) {
^ <=== First time stop == 0 is checked.
stop= bar();
}
}
=
This seems that VRP sees the call to bar() in the wrong place.
Another issue is that VRP sees "i>=0 && !stop", which it translates to:
Visiting statement:
=== This gives a don't know: ===
[delta.c : 5:26] _7 = _6 & _5;
Found new range for _7: [0, +INF]
[snip]
Predicate evaluates to: DON'T KNOW
==
>From there things go downhill. Instead of knowing that _7 implies _5 (i.e.,
i>=0), it loses this information. So VRP does not understand that in the loop
i>= 0.
=== This causes the following:
i_17: loop information indicates does not overflow
Induction variable (int) 9 + -1 * iteration does not wrap in statement i_10 =
i_17 + -1;
in loop 1.
Statement i_10 = i_17 + -1;
is executed at most 2147483657 (bounded by 2147483657) + 1 times in loop 1.
Found new range for i_17: [-INF, 10]
=
If it know that _7 implies _5 and hence i>=0 then it could have understood that
i_17: [0, 10].
= This could lead to missed optimizations (in other cases), and bogus
warnings: ===
Visiting statement:
[delta.c : 5:36] i_10 = i_17 + -1;
Found new range for i_10: [-INF(OVF), 9]
