The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3 in both 32-bit and 64-bit modes.
This is a regression from 5.2.x.
$ gcc-trunk -v
Using built-in specs.
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 20151023 (experimental) [trunk revision 229251] (GCC)
$ gcc-trunk -O2 small.c; ./a.out
$ gcc-5.2 -O3 small.c; ./a.out
$ gcc-trunk -O3 small.c
Aborted (core dumped)
int a = 2, b = 1, c = 1;
for (; a; a--)
for (d = 0; d < 4; d++)
if (c < 1)
c = 0;
b = !1;
if (a != 1)
Started with r226901.
This is a latent problem in ifcvt, that pulls the computation involving the uninitialized k out of the always-false condition. Things go down the hill when k's default def gets coalesced with b, and rtl optimizers further mess things up.
s/ifcvt/ifcombine/ above, sorry
Ok, we shouldn't introduce uninitialized uses. It's going to be interesting to
teach this to ifcombine ;)
Created attachment 36622 [details]
Patch I'm testing to fix the problem
This patch stops ifcombine from introducing this kind of undefined behavior. I'm testing it now, and I'll post it to the list if that completes successfully.
Date: Tue Nov 3 00:30:07 2015
New Revision: 229690
[PR68083] don't introduce undefined behavior in ifcombine
The ifcombine pass may move a conditional access to an uninitialized
value before the condition that ensures it is always well-defined,
thus introducing undefined behavior. Stop it from doing so.
* tree-ssa-ifcombine.c: Include tree-ssa.h.
(bb_no_side_effects_p): Test for undefined uses too.
* tree-ssa.c (gimple_uses_undefined_value_p): New.
* tree-ssa.h (gimple_uses_undefined_value_p): Declare.
* gcc.dg/torture/pr68083.c: New. From Zhendong Su.