[This bug was discovered by kantorzsolt@yahoo.com] When compiling the testcase below at -O2, using gcc 4.3.3 instead of an infite loop, where the variable 'from' takes values from -32768 to 32767, it goes up way beyond that limit: $ gcc -O2 tes -Wall -W -Wstrict-overflow=5 && ./a.out 0 1 ... 2253491 When using -fwrapv, or -fno-strict-overflow 'from' iterates between -32768 and 32767 in an infinite loop, as expected. There are 2 bugs here: - no warning is given with -Wstrict-overflow=5, although -fstrict-overflow changes the behaviour of the code - from is of type short, so when sign extended to an int, it should only take values allowed for a short: -32768 to 32767, not all values allowed for an int (like 2253491) I think this is a bug, because although signed overflow is undefined behaviour, that should affect only the value of 'from', which is still of type 'short', and converting to int should obey the limits for the 'short' type, i.e. use a sign-extension. Here is a diff of the assembly, when using -O2, vs -O2 -fno-strict-overflow: --- x2.s 2009-04-11 15:28:01.000000000 +0300 +++ x2-no-overflow.s 2009-04-11 15:27:58.000000000 +0300 @@ -10,15 +10,16 @@ .LFB13: pushq %rbx .LCFI0: + xorl %esi, %esi xorl %ebx, %ebx .p2align 4,,10 .p2align 3 .L2: - movl %ebx, %esi movl $.LC0, %edi xorl %eax, %eax - call printf addl $1, %ebx + call printf + movswl %bx,%esi jmp .L2 .LFE13: .size main, .-main Testcase: #include <stdio.h> int main () { int until = 40001; short from = 0; for (; from < until; from++) printf ("%d\n", from); return 0; } $ gcc -v Using built-in specs. Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-5' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --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.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --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.3.3 (Debian 4.3.3-5) Also reproduced with trunk: $ ~/gcc_inst/bin/gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../gcc/configure --disable-multilib --disable-static --prefix=/home/edwin/gcc_inst/ --enable-languages=c,c++ Thread model: posix gcc version 4.5.0 20090408 (experimental) [trunk revision 145769] (GCC)
Subject: Re: New: signed overflow in loop induction variable: missing warning and wrong code On Sat, 11 Apr 2009, edwintorok at gmail dot com wrote: > Testcase: > #include <stdio.h> > int > main () > { > int until = 40001; > short from = 0; > > for (; from < until; from++) > printf ("%d\n", from); > > return 0; > } There is no undefined behavior here (increment of a short value converts to int, increments then converts back to short, none of which are undefined), so at least the wrong code issue would be the same as bug 35634.
(In reply to comment #1) > There is no undefined behavior here (increment of a short value converts > to int, increments then converts back to short, none of which are > undefined), so at least the wrong code issue would be the same as bug > 35634. It's not undefined, but the conversion from int back to short provokes implementation-defined behaviour when the int value doesn't fit in a short. That makes this test program not strictly conforming. The lack of a compile-time warning is unfortunate, but I don't think this is a case of wrong-code.
(In reply to comment #2) > (In reply to comment #1) > > There is no undefined behavior here (increment of a short value converts > > to int, increments then converts back to short, none of which are > > undefined), so at least the wrong code issue would be the same as bug > > 35634. > > It's not undefined, but the conversion from int back to short provokes > implementation-defined behaviour when the int value doesn't fit in a short. > That makes this test program not strictly conforming. But converting from short to int for the argument to printf should behave as if a short value was converted to int, i.e. the int value should be in range -32768 to 32767, right?
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > There is no undefined behavior here (increment of a short value converts > > > to int, increments then converts back to short, none of which are > > > undefined), so at least the wrong code issue would be the same as bug > > > 35634. > > > > It's not undefined, but the conversion from int back to short provokes > > implementation-defined behaviour when the int value doesn't fit in a short. > > That makes this test program not strictly conforming. > > But converting from short to int for the argument to printf should behave as if > a short value was converted to int, i.e. the int value should be in range > -32768 to 32767, right? Usually but not here. Since you compiled with -fstrict-overflow (implicitly via -O2) the compiler can assume your short variables will have proper short values. As an optimisation the compiler could decide to store short variables in wider int variables and to perform short arithmetic using int arithmetic. Since you promised not to cause signed overflow those int variables would always be the proper sign-extension of the corresponding short variables. But your test program does cause signed overflow, so this optimisation changes behaviour. It's still not the compiler's fault. If you deliberately cause signed overflow, do not compile with -fstrict-overflow.
(In reply to comment #4) > (In reply to comment #3) > > But converting from short to int for the argument to printf should behave as if > > a short value was converted to int, i.e. the int value should be in range > > -32768 to 32767, right? > > Usually but not here. Since you compiled with -fstrict-overflow (implicitly via > -O2) the compiler can assume your short variables will have proper short > values. As an optimisation the compiler could decide to store short variables > in wider int variables and to perform short arithmetic using int arithmetic. > Since you promised not to cause signed overflow those int variables would > always be the proper sign-extension of the corresponding short variables. > > But your test program does cause signed overflow, so this optimisation changes > behaviour. It's still not the compiler's fault. If you deliberately cause > signed overflow, do not compile with -fstrict-overflow. > Understood. Then this is not wrong code, just a missing warning. (In reply to comment #0) > There are 2 bugs here: > - no warning is given with -Wstrict-overflow=5, although -fstrict-overflow > changes the behaviour of the code This is still a bug: "It warns about cases where the compiler optimizes based on the assumption that signed overflow does not occur." > - from is of type short, so when sign extended to an int, it should only take > values allowed for a short: -32768 to 32767, not all values allowed for an int > (like 2253491) This is not a bug.
(In reply to comment #4) > But your test program does cause signed overflow No, it doesn't. There is a conversion (from int to short) where the value is not representable by the target type, but that is _not_ undefined, but rather implementation-defined, and GCC has chosen to define the conversion as modulo operation. There is no room for GCC to behave differently.
*** This bug has been marked as a duplicate of 35634 ***