http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57719
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2013-06-26
CC| |jakub at gcc dot gnu.org
Target Milestone|--- |4.8.2
Summary|wrong code at -O3 on |[4.8/4.9 Regression] wrong
|x86_64-linux-gnu |code at -O3 on
| |x86_64-linux-gnu
Ever confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
int u, a, b, c[2], d, *e, f, g;
int
foo (void)
{
int t[1], i;
for (i = 0; i < 1; i++)
t[i] = 0;
for (d = 0; d; d = 1)
{
int *s[1] = { &t[0] };
g = a = *s[0];
}
f = g;
return 1;
}
void
bar (void)
{
for (; b < 2; b++)
{
int *p = &u;
*p = 0;
*p = foo ();
e = &c[b];
*e = 0;
}
}
int
main ()
{
bar ();
if (u != 1)
__builtin_abort ();
return 0;
}
Started with r196174. t is discovered unused during dce1 pass, but since
r196174 we no longer remove unused vars, which results in a t ={v} {CLOBBER};
stmt being kept inside of the loop and that for some reason affects lim1
decisions (something to investigate, potential code quality issue).
Anyway, sccp dump still looks good wrt. writes into u; already dse1 removes
the first u = 0; stmt, because it is redundant with following u = 1; in another
bb, but it keeps around u = 0; for the second iteration, so we first enter the
bb with u = 1; from there jump to bb with u = 0;, and from there go to the u =
1; bb back and finally goto exit. In ldist it is already broken, so looks like
a ldist bug to me.
