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
