This is the mail archive of the gcc@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]

Re: Beyond GCC 3.0: Summing Up


Mark Mitchell <mark@codesourcery.com> writes:

>   - It will not contain regressions from the previous release.
> 
>     We will fail, due to undetected bugs, but we can get close.
>     I think most users would like this choice better.
> 
>     We *can* guarantee that there will be no regressions on the GCC
>     testsuite on a given set of target platforms.  That goal is
>     feasibly attainable.

I don't think this is or should be our real goal.  The goal is that
the new release is *better*, according to various metrics, some
subjective.  An easy to way to achieve "better" is to be better in
some aspect, and no worse in all other aspects.  Thus "no worse"
requires "no regressions" on the testsuite, but also in terms of
compilation speed, code quality, error messages, etc.  The testsuite
is not the goal; it is the means by which we measure that things
haven't gotten worse.

For me, "no regressions" is only absolute in the case of changes
that cause the compiler to generate code that yields the wrong
results where it before generated code that was correct.  Any
other regressions are relative, and have to be weighed against
other measures.  If a change causes 2% average better execution
speed, but one platform fails to build, then my inclination
would be to accept the change (assuming no other regressions
and people consider the change architecturally clean), and let
the people (if any) who work on the target fix the problem.

I think the legal term "rebuttable presumption" may be useful.  If you
check something in which causes a regression, then there is a
rebuttable presumption that it is your responsibility to fix the
problem, and if you cannot do so in a timely manner, accept that the
change will be reverted.  The "rebuttable" part means that you have an
option to try to convince people that your change so much improves the
compiler that it more than compensates for the regression.  "People"
in this case means a consensus of the maintainers, with the SC
deciding if there is no consensus.  Both the maintainers and the SC
are expected to give the benefit of the doubt *against* any change that
causes a regression.
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


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