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
