Bug 60229 - wrong code at -O2 and -O3 on x86_64-linux-gnu
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Status: RESOLVED DUPLICATE of bug 35634
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.7.4
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2014-02-16 20:28 UTC by Zhendong Su
Modified: 2014-02-17 09:54 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Zhendong Su 2014-02-16 20:28:05 UTC
The latest gcc 4.7 branch miscompiles the following code on x86_64-linux at -O2 and -O3 in both 32-bit and 64-bit modes.

It also affects 4.6.x, but not 4.8.x and the current gcc trunk. 

The issue seems to be considering signed short and signed char for overflows, but neither overflows. 

$ gcc-trunk -O2 small.c    
$ a.out
$ gcc-4.8.2 -O2 small.c
$ a.out
$ gcc-4.7.3 -O2 small.c
$ a.out
$ gcc-4.7-branch -O2 small.c
$ a.out
$ gcc-4.7-branch -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.7/configure --enable-languages=c,c++
Thread model: posix
gcc version 4.7.4 20140209 (prerelease) [gcc-4_7-branch revision 207641] (GCC) 


short a;

  for (; a >= 0; a++)

  return 0;
Comment 1 Andrew Pinski 2014-02-16 23:09:35 UTC
Dup of bug 35634.

*** This bug has been marked as a duplicate of bug 35634 ***
Comment 2 Andrew Pinski 2014-02-16 23:10:45 UTC
Note there is no overflow happening here at all.  In that a++ is the same as a = a + 1 which is the same as a = (short)(((int)a) + 1) due to promotion rules in C.
Comment 3 Mikael Pettersson 2014-02-17 08:58:34 UTC
Technically there is an overflow there.  But GCC defines conversion to a smaller signed integer type, when the value cannot be represented in that smaller type, as a non-signalling truncation.  Still, portable code mustn't rely on that.
Comment 4 Jakub Jelinek 2014-02-17 09:54:36 UTC
Well, the conversion is implementation-defined behavior, and GCC documents what it does in that case (does it?) and thus you can rely on it, and given that other compilers also have simimilar implementation-defined behavior choice for that case, you can portably assume it unless you are targetting extinct architectures.