* [Bug c/55217] False -Wstrict-overflow warning
2012-11-05 20:21 [Bug c/55217] New: False -Wstrict-overflow warning mattiase at acm dot org
@ 2013-12-14 23:47 ` mickey.veksler at gmail dot com
2014-10-03 22:18 ` [Bug middle-end/55217] " mickey.veksler at gmail dot com
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: mickey.veksler at gmail dot com @ 2013-12-14 23:47 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
Michael Veksler <mickey.veksler at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mickey.veksler at gmail dot com
--- Comment #1 from Michael Veksler <mickey.veksler at gmail dot com> ---
(Strange that this hasn't been confirmed for over a year!)
I have a similar issue with gcc-4.8 with a slightly different test-case.
So first I looked into your test case. To me it seems that gcc-4.7 warning does
look strange here, but with gcc-4.8 things look better:
----
gcc -c -O2 -Wstrict-overflow=2 beta.c -std=c99
beta.c: In function ‘f’:
beta.c:7:20: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
if (r)
^
beta.c:10:17: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
for (int j = 0; j < r; j++)
---
The first warning for if(r) makes sense.
However, the second warning does not make sense. Even after removing the 'if'
the warning stays:
---
void f(int n, int s)
{
int r = 1;
for (int i = 1; i < n; i++)
if (r)
r++;
for (int j = 0; j < r; j++)
h(&s);
}
gamma.c:9:9: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
for (int j = 0; j < r; j++)
---
It is as if gcc transforms the for loop to:
int j=0;
if (j >= r) goto done; // <--- does the warning come from here?
loop:
h(&s);
j++
if (j < r) goto loop;
done:
I assume that then gcc notices that r>=1, unless it overflows, and hence
j>=r must be false for the first j, i.e., j=0.
If this is what happens, then this is the wrong way to do it. If the same
expression is duplicated then -Wstrict-overflow should be emitted only if
it applies to both duplicates, or am I missing something?
>From gcc-bugs-return-437607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Dec 15 00:07:50 2013
Return-Path: <gcc-bugs-return-437607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24956 invoked by alias); 15 Dec 2013 00:07:49 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24936 invoked by uid 48); 15 Dec 2013 00:07:46 -0000
From: "mickey.veksler at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/55217] False -Wstrict-overflow warning
Date: Sun, 15 Dec 2013 00:07:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mickey.veksler at gmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55217-4-5AOBe23r2Q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55217-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55217-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01262.txt.bz2
Content-length: 2295
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #2 from Michael Veksler <mickey.veksler at gmail dot com> ---
A much more clear-cut, weird, and severe case:
$ cat delta.c
int bar();
void foo()
{
int stop= 0;
for (int i=10 ; i>=0 && !stop; --i) {
stop= bar();
}
}
$ gcc -c -O3 -Wstrict-overflow=3 delta.c -std=c99
delta.c: In function ‘foo’:
delta.c:5:22: warning: assuming signed overflow does not occur when changing X
+- C1 cmp C2 to X cmp C1 +- C2 [-Wstrict-overflow]
for (int i=10 ; i>=0 && !stop; --i) {
^
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?
Oh, and:
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.8.1-10ubuntu9' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.1 (Ubuntu/Linaro 4.8.1-10ubuntu9)
>From gcc-bugs-return-437608-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Dec 15 01:59:00 2013
Return-Path: <gcc-bugs-return-437608-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12281 invoked by alias); 15 Dec 2013 01:58:59 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9847 invoked by uid 48); 15 Dec 2013 01:58:54 -0000
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
Date: Sun, 15 Dec 2013 01:58:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libfortran
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jvdelisle at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: assigned_to
Message-ID: <bug-59419-4-bb2EQvrtYu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59419-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59419-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01263.txt.bz2
Content-length: 1065
http://gcc.gnu.org/bugzilla/show_bug.cgi?idY419
Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org
--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
There are 140 calls to generate_error in the library. I have begun an audit of
these and see the "design" plan that was intended. I would like to stick to
that design plan and not modify generate error. Most places are handled
correctly. Generally speaking, after doing multiple groups of error checking
these are checked by lines such as:
if ((opp->common.flags & IOPARM_LIBRETURN_MASK) == IOPARM_LIBRETURN_OK)
This statement checks if all was OK before actually taking any actions. It is
done this way for runtime efficiency.
In short there are a few places where I need to clean up the code a little. I
have started the patch, so will assign this bug to myself.
^ permalink raw reply [flat|nested] 5+ messages in thread* [Bug middle-end/55217] False -Wstrict-overflow warning
2012-11-05 20:21 [Bug c/55217] New: False -Wstrict-overflow warning mattiase at acm dot org
2013-12-14 23:47 ` [Bug c/55217] " mickey.veksler at gmail dot com
@ 2014-10-03 22:18 ` mickey.veksler at gmail dot com
2021-12-13 3:06 ` pinskia at gcc dot gnu.org
2022-02-01 12:53 ` marxin at gcc dot gnu.org
3 siblings, 0 replies; 5+ messages in thread
From: mickey.veksler at gmail dot com @ 2014-10-03 22:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217
--- Comment #5 from Michael Veksler <mickey.veksler at gmail dot com> ---
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 <bb 4>;
else
goto <bb 5>;
==========
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]
^ permalink raw reply [flat|nested] 5+ messages in thread