[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