[Bug c/55217] False -Wstrict-overflow warning

["mickey.veksler at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.