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: regression/ Support --add-passes-despite-regression

> From: Geoff Keating <>
> Date: Sun, 5 Jun 2005 22:27:29 -0700

> On 05/06/2005, at 8:32 PM, Hans-Peter Nilsson wrote:
> > ISTR I've suggested this functionality before but it was turned
> > down as the default because it could cause spurious PASSes.  But
> > that's not a good enough reason: what statistically happens is
> > *not* that some regression somehow causes spurious PASSes, but
> > that a *single* long-standing regression stops
> > regression-checking of test-cases added later.  Not necessarily
> > good for a script that's supposed to test regressions...
> No, the concern is that a patch might break the compiler (for  
> example, have it always return silently with exit status 0) which  
> would cause both regressions and spurious passes; then the patch is  
> fixed, and suddenly a bunch of "regressions" appear which are not  
> really regressions, requiring manual intervention to clear.

Hm, that's what I meant.

> Given that explanation, do you still want this patch?

Yes.  Again, that just doesn't happen often enough to worry
about.  Not compared to the how frequent long-standing
regressions are, which *does* have an impact on the usefulness
of the script without the new option.  Considering risk * cost,
it *would* have a slightly higher cost to clean up spurious
PASSes than to add PASSes when in regression state, but not
linear to the much smaller risk.

>  You might  
> consider that if you're going to be intervening manually anyway, you  
> can just as easily add new passes by hand (after reviewing them) as  
> delete them...

The spurious-pass scenarion happens very rarely, the
everlasting-regression-state half the time, it seems.  I don't
want to manually intervene for that large number of iterations;
this is supposed to be a automatic thing!

> I've already reviewed these in
> <>.

I'm sorry, I missed that.  I can't even blame spam-filters,
because I see I have it in my inbox.  Thanks!

> It would be better to avoid the duplicated code here, and just  
> surround the 'Update the state' code with 'if [ $NUMREGRESS -eq 0 -o  
> $add_passes_despite_regression -ne 0]'.

I thought this edition less risky, but I'll see if I can remove
redundancy with a change like that.

Thanks for the review!

brgds, H-P

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