[Bug c/79025] New: Incorrect loop optimization for -Os and above

[selinger at mathstat dot dal.ca]

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

            Bug ID: 79025
           Summary: Incorrect loop optimization for -Os and above
           Product: gcc
           Version: 6.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: selinger at mathstat dot dal.ca
  Target Milestone: ---

Created attachment 40476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40476&action=edit
Test case

To reproduce:
=============

Consider this minimal example (no includes):

extern int printf (const char *__restrict __format, ...);

int main() {
  int x;

  for (x = 0; x >= 0 && x < 0xffffffff; x += 0x20000000) {
    printf("x=%d\n", x);
  }
  return 0;
}

When compiled with -O0 or -O1, this correctly terminates. When compiled with
-Os or -O2, the check for x >= 0 is ignored and the loop runs forever.

Results:
========

$ gcc -O0 test.c -o test

$ ./test 
x=0
x=536870912
x=1073741824
x=1610612736

$ gcc -O2 test.c -o test

$ ./test 
x=0
x=536870912
x=1073741824
x=1610612736
x=-2147483648
x=-1610612736
x=-1073741824
x=-536870912
x=0
x=536870912
x=1073741824
x=1610612736
x=-2147483648
x=-1610612736
x=-1073741824
x=-536870912
[...]

Compiler and system version:
============================

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 6.2.0-5ubuntu12'
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-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 --enable-multilib
--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 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) 

Additional information: 
=======================

The gcc option -fno-aggressive-loop-optimizations does not fix this bug. 

The gcc option -fdisable-tree-vrp1 appears to fix it.

Secondary bug:
==============

If I replace 0x20000000 by 0x40000000 in the example program, the behavior is
even more bizarre:

extern int printf (const char *__restrict __format, ...);

int main() {
  int x;

  for (x = 0; x >= 0 && x < 0xffffffff; x += 0x40000000) {
    printf("x=%d\n", x);
  }
  return 0;
}

$ gcc -O0 test.c -o test

$ ./test 
x=0
x=1073741824

$ gcc -O2 test.c -o test

$ ./test 
x=0
x=1073741824
x=0
x=1073741824
x=0
[...]

Note that in this case, not only the test for x >= 0 is ignored, but also the
addition is not performed correctly.