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

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

[mattiase at acm dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217

             Bug #: 55217
           Summary: False -Wstrict-overflow warning
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: mattiase@acm.org


This code yields a false -Wstrict-overflow warning in gcc 4.7.2:

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);
}

beta.c:8:12: warning: assuming signed overflow does not occur when assuming
that (X + c) < X is always false [-Wstrict-overflow]

The condition is not on the form X+c<X, and can legitimately go either way.

Here is a variant with s hard-wired to 0. The call to g() seems necessary:

void g(void);
void h(int *s);
void f(int n)
{
        int s = 0;
        int r = 1;
        g();
        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);
}

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

[mickey.veksler at gmail dot com]

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.

[Bug middle-end/55217] False -Wstrict-overflow warning

[mickey.veksler at gmail dot com]

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]

[Bug middle-end/55217] False -Wstrict-overflow warning

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|                            |7.5.0
           Keywords|                            |needs-bisection

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The diagnostic seems to be gone in GCC 8+.

[Bug middle-end/55217] False -Wstrict-overflow warning

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55217

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
Fixed with r8-395-g02c6414935bddf1c.