This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Your patch is causing regressions

> > Sorry, this time this appears to be ommision on my side.
> > I've fully tested the patch on older tree where it did work, then I
> > tested it again together with TREE_ADDRESSABLE fixes and then last time
> > before commiting, but because clean tree bootstrap failed this time
> > (failure appears to be caused by SRA patch), I didn't compared testsuite
> > to something as it seemed as clean improvement.
> > 
> And why are you testing unrelated patches together?  Your verification

I did tested the first separately, later together, then separately again
before commiting.  Problem has been the unrealted bootstrap failure I
described in i386.  I do have script for that and the script decides
that broken bootstrao->bootstrap is always OK.  I now changed it to
always wait for my decision in this case.
> > This ineed is very frustrating.  In both cases the problem of fact that
> > I do not reproduce same bootstrap problems in my setup has been involved.
> > This is very surprising to me and I really hope we will get the tree
> > into more reproducible shape soon.  These kind of problems happens just
> > very rarely for mainline.
> > 
> Look.  It's very simple, you must check each individual patch in a
> different pristine tree.  If the tree changes just before you're about
> to commit your patch, then you must re-start your bootstrap+testing all
> over again.  It's a big hassle, but we all go through it.  Otherwise, we
> end up in the situation we have been during the last week.

OK, my machine needed about 4 hours for testing (compared to 2 hours of
mainline) that is just too long to keep up to date with current tree, so
my script commited in the case update went without conflict.
I've moved to faster machine yesterday and I will change the script to
re-do all the testing again in this scenario.
> It is also very important for you to submit FINAL patches.  I do not
> want to see work-in-progress.  I want to see finished,
> ready-to-be-committed patches.  I want to see very clear indications
> that the patch has passed bootstrap on the couple of platforms you work
> on and there are no regressions in ANY of the testsuites.  I'm dizzy
> from all the different variations of patches that you have been sending
> the last few days.

I got dizzy too by having too many dependencies in between the patches.
The testing code exposed bit too many latent problems many of these I
was not sure how to deal with.  I hope this is under control now.
I will re-send each of the patches from last week and once it passes on
clean tree, I wil send it for review, so you can forget about currently
unreveiwed patches with the exception of take 3 on aliasing fix, OK?
> If a patch of yours exposes problems in other parts of the compiler,
> then you are responsible for fixing them.  Obviously, it's OK to ask for
> help from the person who implemented the failing module.  
> Don't take this personally, this applies to everyone working on the
> branch.  It just happens that this last few days a couple of your
> patches have created problems.
> It is important for the branch to always work.  We are making so many
> changes on a daily basis, that it will be impossible for us to reach a
> mergeable state if we are not draconian about stability.

Agreed.  Sorry for causing too much mess.  I've mande my patch
testing/commiting scripts considerably strickier for tree-ssa so hope
similar scenario is not going to happen again.  Looks like tree-SSA
branch in current shape needs to be dealt with differently than

> I will add this rant to the project page.
> Diego.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]