Bug 39736 - signed overflow in loop induction variable: missing warning and wrong code
signed overflow in loop induction variable: missing warning and wrong code
Status: RESOLVED DUPLICATE of bug 35634
Product: gcc
Classification: Unclassified
Component: tree-optimization
4.3.3
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-04-11 12:30 UTC by Török Edwin
Modified: 2009-04-13 08:19 UTC (History)
10 users (show)

See Also:
Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
Build: x86_64-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Török Edwin 2009-04-11 12:30:32 UTC
[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)
Comment 1 joseph@codesourcery.com 2009-04-11 12:51:47 UTC
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.

Comment 2 Mikael Pettersson 2009-04-12 09:11:14 UTC
(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.
Comment 3 Török Edwin 2009-04-12 09:32:42 UTC
(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?

Comment 4 Mikael Pettersson 2009-04-12 21:33:45 UTC
(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.
Comment 5 Török Edwin 2009-04-13 06:56:20 UTC
(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.
Comment 6 Andreas Schwab 2009-04-13 07:53:39 UTC
(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.
Comment 7 Richard Biener 2009-04-13 08:19:57 UTC

*** This bug has been marked as a duplicate of 35634 ***