Re: [PATCH] Fix bootstrap (PR rtl-opt/29879)

[Andrew Pinski <pinskia at gmail dot com>]

On Sun, 2006-11-19 at 20:50 -0700, Roger Sayle wrote:
> On Sun, 19 Nov 2006, Andrew Pinski wrote:
> >
> > 	* fwprop.c (loops): Remove.
> > 	(forward_propagate_into): Use current_loops instead of
> > 	loops.
> > 	(fwprop_init): Call loop_optimizer_init instead of
> > 	flow_loops_find.
> > 	(fwprop_done): Call loop_optimizer_finalize instead of
> > 	flow_loops_free.
> > 	(fwprop): Use current_loops instead of loops.
> 
> This is OK for mainline, with the minor modification recommended by
> Zdenek, that it need not test current_loops->num anywhere.

Thanks, I committed that patch with removing the test for
current_loops->num.

> Many thanks to Andrew for fixing the bootstrap failure, and to both
> Zdenek and Paolo for confirming that the fix is correct.
> 
> Now the task of figuring out why this wasn't caught in testing prior
> to being committed.  Presumably an incompatible change to loop handling
> has collided with fwprop during stage 1?

I think what happened was Zdenek posted his patch on the 23rd of October
and was not approved (and applied) until after fwprop was added.  And
there was no retesting of the patch after Zdenek's patch was applied.

Maybe a policy of two weeks old patches during stage1 (and maybe a month
old in stage2/3) should be rested before applying them.  This should
help out resolving conflicts on patches which were posted a while back
and ones which were just applied.
This will not resolve all conflicts but some which are the more painful
ones like this one.

Maybe instead a policy where checking patches cause the trunk to be
frozen until it is tested on at least two targets and then applied.  And
require all patches (which could have an effect cause by the checking)
after that be but retested after the new checking patch was applied.
This should resolve all checking caused conflicts but it does cause
people to wait for bootstraps and the trunk being frozen.

I like the second proposal better but I feel it is going over the top of
what is acceptable in a free source project and resources are sometimes
hard to come by.

Thanks,
Andrew Pinski