[tree-ssa] bug analysis for 20000603-1.c

law@redhat.com law@redhat.com
Tue Oct 14 00:40:00 GMT 2003


In message <1066083523.27865.34.camel@steven.lr-s.tudelft.nl>, Steven Bosscher 
writes:
 >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.
This testcase has been extensively analyzed.  AT this time it's not 100%
clear if the code in the test is valid or not.

jeff



More information about the Gcc mailing list