Re: [tree-ssa] Operand management II

[Jan Hubicka <hubicka at ucw dot cz>]

> On Wed, 2003-12-17 at 06:45, Jan Hubicka wrote:
> > > In message <1071610959.13039.192.camel@p4>, Andrew MacLeod writes:
> > >  >Now, I've discovered something very interesting along the way. The SSA
> > >  >verifier is not catching all the problems we have. In fact, when I first
> > >  >enabled this, I had 45 more failures in the gcc testsuite, all due to
> > >  >the verifier.
> > >  >
> > >  >It turns out that an optimization can do something incorrect, like
> > >  >remove a VDEF which still has uses, and the verifier may not catch it
> > >  >because when it looks at SSA_NAE_DEF_STMT(ssa_name), it still points to
> > >  >the old VDEF which was deleted.  AS long as that memory hasn't been
> > >  >stomped on, it still looks fine. Ahhhh. So what was happening, I was
> > >  >freeing an operand, overwriting the first word to use as a 'next'
> > >  >pointer, and voila, it triggers the ssa verifier since it is no longer
> > >  >correct.
> > > FWIW, Jan has some improvements to the verification code which may 
> > > (or may not) help detect this stuff.
> > 
> > I don't detect this directly now.  But if there is "released" bit
> > somewhere in the datstructure, like SSA_NAMEs, it is all easy - all you
> > need is to check that the bit is not set during checking.  verify_ssa is
> > convenient place for this.  Alternate plan is to do ENABLE_CHECKING
> > memset in the "free" call.
> > > 
> 
> I'm going to look at it today, Im seeing some inconsistancy, so it might
> very well be my free list that is the culprit :-). We'll see

In the case you leave VUSES of operand and you remove all VDEFS and run
verify_ssa, you should see failure about uninitialized VUSE too.
verify_ssa verifies all dominance relationships in between uses and
defs.

Honza
> 
> Andrew