This is the mail archive of the
mailing list for the GCC project.
Re: regression/btest-gcc.sh: Support --add-passes-despite-regression
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: geoffk at geoffk dot org
- Cc: hans-peter dot nilsson at axis dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Jun 2005 07:54:03 +0200
- Subject: Re: regression/btest-gcc.sh: Support --add-passes-despite-regression
> From: Geoff Keating <firstname.lastname@example.org>
> 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!