This is the mail archive of the
mailing list for the GCC project.
GCC 3.0 Branch: Guidelines
- To: gcc at gcc dot gnu dot org
- Subject: GCC 3.0 Branch: Guidelines
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 12 Feb 2001 15:47:46 -0800
- Organization: CodeSourcery, LLC
As you know, we have branched for GCC 3.0. That implies that we are,
for the most part, feature complete.
This mail contains draft guidelines for how we should handle check-ins
on the branch. If there is widespread disagreement, we (or the SC)
can certainly choose other guidelines, but I think these will be
If you have questions, ask them on this list. I'll try to reply as
best I can.
Mark Mitchell firstname.lastname@example.org
CodeSourcery, LLC http://www.codesourcery.com
The goal of any change checked in on the branch should be one of:
- Fix a regression relative to GCC 2.95..
Specifically, this covers:
- Legal code that used to compile, but now doesn't.
- Code that used to produce a meaningful error message, but now
causes a crash.
- Code for which we used to generate correct code, but for
which we now generate incorrect code.
- Code which used to run quickly now runs markedly slower.
- Other similar situations.
- Improve compile-time performance.
It is widely recognized that compile-time performance is a
problem in the current sourc-base. We need to work on that.
Changes that speed up the compiler are fine, even if they do fix
a bug. (In some sense, you can consider these fixes for
regressions, but let's use the term regression to apply to
everything *but* compile-time performance. In other words,
regressions are things that involve the abstract performance of
the compiler, independent of how long it takes to run, or how much
memory it uses.)
- Fix an egregious bug, even though such a bug also appeared in GCC
This guideline should not be abused. A bug is not necessarily
egregious because it appears in a piece of software you use. Or
even a piece of software lots of people use. Here are some
examples that would qualify:
- We miscompile the Linux kernel.
This is an extremely piece of software from the point of view of
the GNU Project; therefore, it must work correctly. X Windows
would also qualify. The KDE CD player probably would not.
(Note that here we are assuming the code did not work with GCC
- We emit an error message that is so misleading as to make
fixing the first problem that appears in the source file
next to impossible.
- Other similar situations.
Judgement is clearly required here. If too many things seem
to be being checked in under this rule, we'll have to set clearer
guidelines, but I think that we'll develop a good feel as we
- Platform-specific fixes that enable platforms that do not
presently work to work.
Examples would include:
- Fixing the HPUX back-end so that HPUX successfully bootstraps.
- Making Makefile changes to enable the shared libgcc on platforms
that do not presently have it.
These changes must be sufficiently machine-specific so that is is
clear that they will not affect other machines.
- Some other miscellaneous, but worthwhile goal.
I'm not really sure what these would be, but they might include
making the compiler easier to configure, improving the packaging,
fixing version numbers associated with various things, or what
have you. Let's take these case by case.
Not all patches that meet the above guidelines should be checked in.
The benefits of every patch should be weighed against the likelihood
of breakage. Small changes are to be preferred to big ones. Rather
than rewriting large chunks of code, we should endeavor to find
surgical changes that solve particular problems. (That said, there
might still be moderately-sized chunks of the compiler that should be
entirely rewritten, even on the branch; that might be the best way to
solve a pervasive problem.) In general, the goal is to avoid
regressions on the branch.
All the usual maintainers can (and should!) approve patches for the
branch, following the guidelines above.