[Bug c/41649] New: Optimizer makes wrong integer arithmetic assumption

[enrico dot kravina at gmail dot com]

Consider this simple program

int main(){
  int a=0;
  while (a>=0) a+=1;
}

compiled with this version of gcc: (The bug also manifested in later versions)
:~$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,fortran,objc,obj-c++,treelang
--prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext
--enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.2
--program-suffix=-4.2
--enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr
--enable-targets=all
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.2.4 (Ubuntu 4.2.4-1ubuntu4)

Compiling without optimization and with -O2 gives two completely different
results

:~/work/sysprog/perf$ g++ cnt.c -o cnt; time ./cnt
real 0m1.199s
user 0m1.200s
sys 0m0.000s

:~/work/sysprog/perf$ g++ -O2 cnt.c -o cnt && time ./cnt
<DOES NOT HALT!>
Examining the assembly code it is clear why:

Without optimization we get

movl $0, %eax
.L2:
addl $1, %eax
jns .L2

And with O2 we get:

.L2:
jmp .L2

As I understand, a C program working with integers should not change its
semantics depending on the optimization switch. It would have been fine
to remove the loop completely but not to turn it into an infinite loop.


-- 
           Summary: Optimizer makes wrong integer arithmetic assumption
           Product: gcc
           Version: 4.2.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: enrico dot kravina at gmail dot com
 GCC build triplet: IA32, Linux, gcc 4.2 (and later)
  GCC host triplet: IA32, Linux
GCC target triplet: IA32, Linux


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