This is the mail archive of the gcc-patches@gcc.gnu.org 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: [PATCH] Temporarily enable ac_fold_checking for --enable-checking=yes.


On 6/23/07, Mark Mitchell <mark@codesourcery.com> wrote:
Richard Guenther wrote:

>> Maybe we could have one or two people running autotesters with lots and
>> lots of checking turned on, and then reinforce the idea that a solemn
>> responsibility of contributing GCC is fixing regressions that you
>> introduce?
>
> And I am definitely against this.  I would even make our current rules
> stricter and require bootstrap even for frontend-only changes.  Automatic
> testing is cheap - even if it takes a while.  Going through testresults,
> filing
> bugs and going after the people that introduced them is not.
>
> Let's not waste other peoples time for the sake of your own ease.

Just to clarify - the 'your' was more an 'our'.


I didn't make a very concrete proposal because I'm not sure I have a
very good one to make.  I certainly agree with you that people are a lot
more expensive than computers.

But, I hope you don't think that this is just me being selfish.  It
could be that I'm a lot less good at multitasking than you are.  But, I
really do think that throughput (total changes we can make) is somewhat
affected by latency (speed at which we can make a single change).

I think we are having enough "throughput" already, and latency helps you think over what you do (that at least happens for me). Of course there are the very simple changes where throughput may be an issue, but still I tend to lump the simple changes into one bootstra/testing cycle over night. And who cares if there's a night inbetween developing and applying a patch.

I think it's reasonable to do some cost-benefit analysis.  For example,
we'd probably agree that testing that caught one bug every 100 years but
which took up 99% of our testing time would not be worthwhile to impose
on everyone.  So, it's not an absolute thing; we should be looking for a
way to do testing that delivers most of the benefit with only some of
the cost.

Which is why I agreed on your overall remarks about testing. Over time we have accumulated a _lot_ of tests that happen to not test anything anymore (or at least something different now), partly due to the lack of proper unit-testing.

So, a testcase-police or as others suggested, splitting the testsuite to
have parts that are not run by default (like libstdc++ performance
testsuite) is a good idea.  But also work that somebody needs to do.

I think not bootstrapping for a front-end change is a reasonable
tradeoff.

For a possibly broken bootstrap? I think a broken bootstrap is worse than some failing tests in the testsuite. But your mileage may vary ;)

I think not running tests on multiple platforms when making a
small change to the middle-end is a reasonable tradeoff too.  Maybe we
should add more testing than we're doing to reach an optimal point;
maybe we should be doing less; maybe we should be shifting the testing
load around in some way.  I don't know.  But, I wanted to raise the
general issue and to express concern, in the context of discussion about
a change that might add an hour to the bootstrap-test cycle time.

Sure. Automated testers which do additional testing to bootstrap and regtest are very valuable. At SUSE we compile lots of testsuites and applications on a daily basis with trunk - still noticing a regression and filing a proper bugreport thakes time. Time that I could do gcc development in - which closes the cycle ;)

Richard.


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