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