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

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

[Steven Bosscher]

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

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

[law]

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

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

[Steven Bosscher]

Op di 14-10-2003, om 00:47 schreef law@redhat.com:
> This testcase has been extensively analyzed.

Well, mind sharing with us what other test cases have also already been
analyzed, so there's not too much duplication of effort?

> AT this time it's not 100%
> clear if the code in the test is valid or not.

It has been like this since a long time, according to
http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00081.html.  Perhaps time
to get let loose the language lawyers on this one :-)

Gr.
Steven

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

[law]

In message <1066085644.16921.40.camel@steven.lr-s.tudelft.nl>, Steven Bosscher 
writes:
 >Op di 14-10-2003, om 00:47 schreef law@redhat.com:
 >> This testcase has been extensively analyzed.
 >
 >Well, mind sharing with us what other test cases have also already been
 >analyzed, so there's not too much duplication of effort?
 >
 >> AT this time it's not 100%
 >> clear if the code in the test is valid or not.
 >
 >It has been like this since a long time, according to
 >http://gcc.gnu.org/ml/gcc-patches/2000-06/msg00081.html.  Perhaps time
 >to get let loose the language lawyers on this one :-)
Even the language lawyers aren't exactly sure on this one...

jeff

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

[law]

In message <1066085644.16921.40.camel@steven.lr-s.tudelft.nl>, Steven Bosscher 
writes:
 >Op di 14-10-2003, om 00:47 schreef law@redhat.com:
 >> This testcase has been extensively analyzed.
 >
 >Well, mind sharing with us what other test cases have also already been
 >analyzed, so there's not too much duplication of effort?
Well, I know what the tree-ssa.exp failures are since I cobbled together
most of those tests.  I think everyone else just ignores them :-)

Jeff

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

[Richard Henderson]

On Mon, Oct 13, 2003 at 07:45:22PM -0600, law@redhat.com wrote:
>  >Well, mind sharing with us what other test cases have also already been
>  >analyzed, so there's not too much duplication of effort?
> Well, I know what the tree-ssa.exp failures are since I cobbled together
> most of those tests.  I think everyone else just ignores them :-)

I've been trying to work the last two weeks or so fixing or
xfailing all of them.  We really need to be able to tell at
a glance whether a patch causes a regression.


r~

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

[Steven Bosscher]

Op di 14-10-2003, om 09:30 schreef Richard Henderson:
> On Mon, Oct 13, 2003 at 07:45:22PM -0600, law@redhat.com wrote:
> >  >Well, mind sharing with us what other test cases have also already been
> >  >analyzed, so there's not too much duplication of effort?
> > Well, I know what the tree-ssa.exp failures are since I cobbled together
> > most of those tests.  I think everyone else just ignores them :-)
> 
> I've been trying to work the last two weeks or so fixing or
> xfailing all of them.  We really need to be able to tell at
> a glance whether a patch causes a regression.

Oh, I didn't know you were going through all of 'em.  I started looking
at them yesterday because there are so many and they've been around for
so long :-)  There really should be a plan for what to do about all
those builtins failures...

Any reason why noreturn-1.c and return-type-1.c have the wrong line for
a warning?  All other tests for these warnings have them at the right
lines.

Gr.
Steven


Index: noreturn-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/noreturn-1.c,v
retrieving revision 1.7.28.3
diff -c -3 -p -r1.7.28.3 noreturn-1.c
*** noreturn-1.c	11 Mar 2003 00:15:13 -0000	1.7.28.3
--- noreturn-1.c	13 Oct 2003 23:27:13 -0000
*************** extern void exit (int);
*** 7,14 ****
  extern void foo1(void) __attribute__ ((__noreturn__));
  void
  foo1(void)
! { /* { dg-warning "`noreturn' function does return" "detect falling off end of noreturn" } */
! }
  
  extern void foo2(void) __attribute__ ((__noreturn__));
  void
--- 7,14 ----
  extern void foo1(void) __attribute__ ((__noreturn__));
  void
  foo1(void)
! {
! }  /* { dg-warning "`noreturn' function does return" "detect falling off end of noreturn" } */
  
  extern void foo2(void) __attribute__ ((__noreturn__));
  void
Index: return-type-1.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/testsuite/gcc.dg/return-type-1.c,v
retrieving revision 1.3.26.3
diff -c -3 -p -r1.3.26.3 return-type-1.c
*** return-type-1.c	11 Mar 2003 00:15:13 -0000	1.3.26.3
--- return-type-1.c	13 Oct 2003 23:27:13 -0000
***************
*** 5,9 ****
  /* { dg-options "-O -Wreturn-type" } */
  int
  foo(void)
! { /* { dg-warning "control reaches end of non-void function" "warning for falling off end of non-void function" } */
! }
--- 5,9 ----
  /* { dg-options "-O -Wreturn-type" } */
  int
  foo(void)
! {
! }  /* { dg-warning "control reaches end of non-void function" "warning for falling off end of non-void function" } */

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

[Richard Henderson]

On Tue, Oct 14, 2003 at 09:42:42AM +0200, Steven Bosscher wrote:
> Any reason why noreturn-1.c and return-type-1.c have the wrong line for
> a warning?  All other tests for these warnings have them at the right
> lines.

These two must have already been tweeked for the branch.

Mainline does put the warning at the end of the function,
and I had tweeked branch to match (which fixed oodles of
other tests).


r~

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

[law]

In message <20031014073000.GB27340@redhat.com>, Richard Henderson writes:
 >On Mon, Oct 13, 2003 at 07:45:22PM -0600, law@redhat.com wrote:
 >>  >Well, mind sharing with us what other test cases have also already been
 >>  >analyzed, so there's not too much duplication of effort?
 >> Well, I know what the tree-ssa.exp failures are since I cobbled together
 >> most of those tests.  I think everyone else just ignores them :-)
 >
 >I've been trying to work the last two weeks or so fixing or
 >xfailing all of them.  We really need to be able to tell at
 >a glance whether a patch causes a regression.
I won't disagree at all.  Each merge has tended to bring in new tests
which fail for one reason or another.  We tend to hit a critical mass of
failures, then someone (Diego, myself, now you) goes through and nails as
many as they can and the cycle starts again.

It's one of the reasons why I think it's critical that we be focused on the
goal of getting this work into the mainline sources. :-)

jeff