[tree-ssa] bug analysis for 20000603-1.c
Steven Bosscher
s.bosscher@student.tudelft.nl
Mon Oct 13 23:06:00 GMT 2003
Hi,
Dunno if anyone had already looked at some of the too-many failures on
tree-ssa, but I've got a reduced test case for 20000603-1.c here:
struct s1 { double d; };
struct s2 { double d; };
int
main(void)
{
struct s1 a;
a.d = 0.0;
((struct s2 *) &a)->d = 1.0;
if (a.d != 1.0)
abort ();
return 0;
}
This works at and -O1, but aborts at -O2.
Apparently there is some tree alias-analysis we do at -O2 (I didn't know
that -- what/where is it?). We mess things up there: At -O1 we properly
have a VDEF for a for the "((struct s2 *) &a)->d = 1.0;" assignment, but
at -O2 that is suddenly turned into a VDEF of a memory tag that wasn't
there before:
t12.ssa1 dump at -O1:
# a_2 = VDEF <a_1>;
a.d = 0.0;
a.1_3 = (struct s2 *)&a;
# a_4 = VDEF <a_2>;
a.1_3->d = 1.0e+0;
# VUSE <a_4>;
T.2_5 = a.d;
if (T.2_5 != 1.0e+0)
t12.ssa1 dump at -O2:
# a_2 = VDEF <a_1>;
a.d = 0.0;
a.1_3 = (struct s2 *)&a;
# MT.1_5 = VDEF <MT.1_4>;
a.1_3->d = 1.0e+0;
# VUSE <a_2>;
T.2_6 = a.d;
if (T.2_6 != 1.0e+0)
So at -O2 we fail to notice that the assignment to a.1_3 is a necessary
store, and DCE kills it: Deleting : a.1_3->d = 1.0e+0.
Gr.
Steven
More information about the Gcc
mailing list