Mainline bootstrap failure (revision 110017)

[Zdenek Dvorak]

Hello,

> > > >>>The attached fixes *that*, but this just causes a crash deeper in trying 
> > > >>>to free some chains.
> > > >>>      
> > > >>[...]
> > > >>Sorry for the problems and thanks for looking into them.
> > > >>    
> > > >
> > > >Ken, please reread the email.  The issue is *not* fixed according to
> > > >Daniel, there's still another problem.  Could you look into it,
> > > >please?
> > > >
> > > I would like permission to revert zdenek's patch for a few days.  There 
> > > is nothing wrong with zdenek's patch, pe se, but it excercises a part of 
> > > df that should work but does not.
> > 
> > I don't quite like this idea; as you yourself say, the problem is not in
> > that patch (in fact, mainline bootstraps and passes regtesting with it
> > without your patch); so I think that if we indeed want to go into
> > reverting patches, it should be the one causing the problem (and I have
> > a followup patch that I would like to be able to test).
> > 
> > Btw.: of course it may happen that some patch sometimes breaks
> > bootstrap, it happened to everyone of us.  But, with your patch, not
> > even libgcc builds.  This means that you did not even try to build gcc
> > before commiting your patch.
> 
> This is simply not true.
> I in fact, watched him bootstrap and regtest it multiple times.
> It simply happened that 10 minutes before he committed his patch, you
> committed yours.
> Please don't go accusing people of not bootstrapping, etc.

I do not accuse him of not testing it; of course that he tested it
properly.  I just say that he should have at least build the branch in
the state in that he wanted to commit it.  It takes just a few minutes,
and if someone makes change during that time, rebuilding to verify that
these did not break something takes just a few seconds.

> > > We could revert my storage patch, but the problem is much deeper than 
> > > that.  The storage patch only causes this problem to happen when 
> > > bootstrapping.  The problem will still be there and may cause random 
> > > ices when running zdeneks code.
> > > 
> > > The problem is that when ever you delete any basic blocks, you need to 
> > > get rid of the def use and use def chains that either start or end in 
> > > the deleted block, furthermore,  this has to be done before the 
> > > instructions are deleted for those blocks.  This will take me a day to 
> > > get correct.
> > > Zdenek's patch is the only code that manipulates the blocks after 
> > > use-def or def-use chains are built.
> > 
> > This analysis seems wrong to me -- the crash occurs when called from
> > estimate_probability, and we do not change CFG in branch prediction.
> 
> The crash occurs from df_set_blocks called from iv_analysis.
> Not sure what you are referring to.
> 
> His analysis of what is going on is completely correct.

"that manipulates the blocks after use-def or def-use chains are built":
the place from that the function is called does not manipulate blocks in
any way, the only thing it does is setting probabilities of edges.

Zdenek