This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Your patch is causing regressions
On Fri, 2003-11-21 at 18:25, Jan Hubicka wrote:
> > So did you actually test this patch?
> > 2003-11-21 Jan Hubicka <firstname.lastname@example.org>
> > * tree-dfa.c (get_expr_operands): Fix handling of CALL_EXPR.
> > * tree-must-alias.c (tree_compute_must_alias): promote pointers.
> > (find_addressable_vars): Deal with complex constant expressions;
> > do not clear may_point_to_global_mem.
> > It's clearly causing regressions on i686-pc-linux-gnu.
> > GCC:
> > ! FAIL: gcc.c-torture/execute/980701-1.c execution, -O3
> > -fomit-frame-pointer
> > ! FAIL: gcc.c-torture/execute/980701-1.c execution, -O3 -g
> > libstdc++:
> > ! FAIL: 23_containers/vector/cons/4.cc execution test
> > ! FAIL: 24_iterators/iterator.cc execution test
> > If our policies on testing are not clear enough, if you're going to
> > contribute changes, they must be bootstrapped and regression tested
> > on i686-pc-linux-gnu. I don't want to see a patch submitted for
> > integration until those tests have completed and passed successfully.
> 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
patch is still exposing problems, you ought to have it in a separate
tree until you figure out the exact root of the problem and fix it or
give enough information to have it fixed. In the case of the
verification failure after the SRA pass, we've established that it seems
to be a renaming problem. I will try to look at it next week, but it is
important for you not to mix different patches (is the version of the
verification patch you sent me the final one?)
> 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.
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.
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.
I will add this rant to the project page.