[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