Bug 66186 - [5 Regression] wrong code at -O3 on x86_64-linux-gnu
Summary: [5 Regression] wrong code at -O3 on x86_64-linux-gnu
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 6.0
: P2 normal
Target Milestone: 6.0
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2015-05-17 19:20 UTC by Zhendong Su
Modified: 2017-10-10 14:56 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-05-18 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Zhendong Su 2015-05-17 19:20:30 UTC
The current gcc trunk (as well as 4.9.x and 5.1.x) miscompiles the following code on x86_64-linux at -O3 in both 32-bit and 64-bit modes. 

This is a regression from 4.8.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150517 (experimental) [trunk revision 223265] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-4.8.4 -O3 small.c; ./a.out
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ gcc-5.1 -O3 small.c 
$ ./a.out
Segmentation fault (core dumped)
$ gcc-4.9.2 -O3 small.c
$ ./a.out
Segmentation fault (core dumped)
$ 


--------------------------------------


int a;

int
main ()
{
  int b = -1, d, e = 0, f[2] = { 0 };
  unsigned short c = b;
  for (; e < 3; e++)
    for (d = 0; d < 2; d++)
      if (a < 0)
	for (d = 0; d < 2; d++)
	  if (f[c])
	    break;
  return 0;
}
Comment 1 Jakub Jelinek 2015-05-18 07:05:54 UTC
Started with r204458.  But most likely this is yet another case of the RTL bug where stack pointer based accesses are considered as non-trapping, despite being clearly out of bounds.
The pcom change only changed
f_I_lsm0.4_7 = f[65535];
which the compiler can see as being out of bounds access quickly (note, f is int f[2]), but after the pcom change it uses
f_I_lsm0.4_7 = MEM[(int *)&f + 262140B];
and for some reason we don't consider that as clearly out of bounds access.
Comment 2 Jakub Jelinek 2015-06-26 19:59:22 UTC
GCC 4.9.3 has been released.
Comment 3 Mikael Pettersson 2015-07-03 14:30:45 UTC
This test case got fixed on trunk by r225260 (PR61047 fix).
Comment 4 Richard Biener 2016-08-03 11:45:38 UTC
GCC 4.9 branch is being closed
Comment 5 Jakub Jelinek 2017-10-10 13:46:47 UTC
GCC 5 branch has been closed, should be fixed in GCC 6 and later.