[Contents] [Back] [Prev] [Up] [Next] [Forward]
If you would like to write bug fixes or improvements for the GNU C
compiler, that is very helpful. Send suggested fixes to the bug report
Please follow these guidelines so we can study your patches efficiently.
If you don't follow these guidelines, your information might still be
useful, but using it will take extra work. Maintaining GNU C is a lot
of work in the best of circumstances, and we can't keep up unless you do
your best to help.
Send an explanation with your changes of what problem they fix or what
improvement they bring about. For a bug fix, just include a copy of the
bug report, and explain why the change fixes the bug.
(Referring to a bug report is not as good as including it, because then
we will have to look it up, and we have probably already deleted it if
we've already fixed the bug.)
Always include a proper bug report for the problem you think you have
fixed. We need to convince ourselves that the change is right before
installing it. Even if it is right, we might have trouble judging it if
we don't have a way to reproduce the problem.
Include all the comments that are appropriate to help people reading the
source in the future understand why this change was needed.
Don't mix together changes made for different reasons.
Send them individually.
If you make two changes for separate reasons, then we might not want to
install them both. We might want to install just one. If you send them
all jumbled together in a single set of diffs, we have to do extra work
to disentangle them--to figure out which parts of the change serve
which purpose. If we don't have time for this, we might have to ignore
your changes entirely.
If you send each change as soon as you have written it, with its own
explanation, then the two changes never get tangled up, and we can
consider each one properly without any extra work to disentangle them.
Ideally, each change you send should be impossible to subdivide into
parts that we might want to consider separately, because each of its
parts gets its motivation from the other parts.
Send each change as soon as that change is finished. Sometimes people
think they are helping us by accumulating many changes to send them all
together. As explained above, this is absolutely the worst thing you
Since you should send each change separately, you might as well send it
right away. That gives us the option of installing it immediately if it
Use `diff -c' to make your diffs. Diffs without context are hard
for us to install reliably. More than that, they make it hard for us to
study the diffs to decide whether we want to install them. Unidiff
format is better than contextless diffs, but not as easy to read as
If you have GNU diff, use `diff -cp', which shows the name of the
function that each change occurs in.
Write the change log entries for your changes. We get lots of changes,
and we don't have time to do all the change log writing ourselves.
Read the `ChangeLog' file to see what sorts of information to put
in, and to learn the style that we use. The purpose of the change log
is to show people where to find what was changed. So you need to be
specific about what functions you changed; in large functions, it's
often helpful to indicate where within the function the change was.
On the other hand, once you have shown people where to find the change,
you need not explain its purpose. Thus, if you add a new function, all
you need to say about it is that it is new. If you feel that the
purpose needs explaining, it probably does--but the explanation will be
much more useful if you put it in comments in the code.
If you would like your name to appear in the header line for who made
the change, send us the header line.
When you write the fix, keep in mind that we can't install a change that
would break other systems.
People often suggest fixing a problem by changing machine-independent
files such as `toplev.c' to do something special that a particular
system needs. Sometimes it is totally obvious that such changes would
break GNU CC for almost all users. We can't possibly make a change like
that. At best it might tell us how to write another patch that would
solve the problem acceptably.
Sometimes people send fixes that might be an improvement in
general--but it is hard to be sure of this. It's hard to install
such changes because we have to study them very carefully. Of course,
a good explanation of the reasoning by which you concluded the change
was correct can help convince us.
The safest changes are changes to the configuration files for a
particular machine. These are safe because they can't create new bugs
on other machines.
Please help us keep up with the workload by designing the patch in a
form that is good to install.
[Contents] [Back] [Prev] [Up] [Next] [Forward]