Re: Mainline bootstrap failure (revision 110017)

[Kenneth Zadeck <zadeck at naturalbridge dot com>]

This fixes the problems that became apparent from zdeneks patch.

Bootstrapped and regression tested against the version with zdenek's 
original code (since this directly tickled the failure and bootstrapped 
(and in the process of regression testing) against the current mainline. 
Both on i686-pc-linux-gnu.

Kenny


2005-01-20  Kenneth Zadeck <zadeck@naturalbridge.com>

  * df-scan.c (problem_SCAN): Added NULL reset function.
  (df_scan_reset_blocks): Added code to call reset block function
  (df_bb_refs_delete) Fixed comment.
  (df_insn_refs_delete): Made tolerant of deleting non existent info
  for dataflow problems that need to be reset.
  * df-core.c (df_set_blocks): Ditto.
  * df.h (struct df_problem): Added reset_fun.
  * df-problems.c (problem_RU, problem_RD, problem_LR, problem_UR,
  problem_UREC, problem_CHAIN, problem_RI): Initialized reset_fun field.
  (df_chain_insn_reset, df_chain_bb_reset, df_chain_reset): New
  functions to clear out all references to def-use or use-def chains.


Zdenek Dvorak wrote:
> 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.  Please do that next time.  In fact,
> running at least a partial bootstrap till gengtype is run helped me
> avoid introducing bootstrap failures (caused by unexpected interaction
> with patches commited since I tested the patch fully the last time)
> several times, so it is a good idea even if you are quite sure that no
> such problem may occur.
>
>   
> > 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.
>
> Zdenek
>