email-based regression search server
Janis Johnson
janis187@us.ibm.com
Wed Feb 5 23:35:00 GMT 2003
On Wed, Feb 05, 2003 at 03:05:54PM -0800, Joe Buck wrote:
> On Wed, Feb 05, 2003 at 02:43:49PM -0500, Phil Edwards wrote:
> > It can now also look for the opposite situation: the input code was broken,
> > but now compiles. (I don't know of an example.)
>
> One reason someone might want that is if they know that someone fixed
> a failure on one branch, and they want to figure out what the fix was,
> for the purpose of porting the fix to another branch.
>
> > Input test code that worked, then broke, then worked, then broke, etc, will
> > naturally drive the hunter nuts. Like you'd expect with a binary search.
>
> If the binary search always halves the range, it would seem that it will
> still converge to something in log(N) steps. Is there something I'm
> missing?
>
> That is, the search is designed for searching a series of points that
> look like this:
>
> P P P P P P F F F F
> ^--------first failure.
>
> If instead you have
>
> P P F F P P P P F F F F
>
> then you know that you will find an F that is immediately preceded by
> a P, but you don't know which one you'll get.
>
> Right?
It will converge, but the result won't make any sense, in that the patch
that is found won't have anything to do with the test. I ran into that
with some of the regression hunts I did, and ended up identifying patches
for different target support being responsible for regressions on i686.
Janis
More information about the Gcc
mailing list