Return to README-bugs CVS log

Up to [GCC 2.x] / gcc

gcc-2.1

If you encounter a problem in GCC, what should you do?

You should send a bug report.

Here are some tips for how you can report problems in GCC effectively.
All of them follow from common sense together with the nature of the
purpose and the situation.

* It is absolutely vital that you tell me about even the smallest
change or departure from the standard sources and procedure.

Otherwise, you are not testing the same program that I asked you to
test.  Testing a different program is usually of no use whatever.  It
can even cause trouble if you fail to tell me that you tested some
other program instead of what I am about to release.  I might think
that GCC works, when in fact it has not even been tried, and might
have a glaring fault.

* Even changing the compilation options counts as a change in the
program.  The GCC sources specify which compilation options to use.
Some of them are specified in machine-specific configuration files.
They also give you ways to override this--but if you do, then you are
not testing what ordinary users will do.  Therefore, when pretesting,
it is vital to test with the default compilation options.

(Testing with a different set of options can be useful *in addition*,
but not *instead of* the default options.)

* The machine and system configuration files of GCC are parts of
GCC.  So when you test GCC, you need to do it with the
configuration files that come with GCC.

If GCC does not come with configuration files for a certain machine,
and you test it with configuration files that don't come with GCC,
this is effectively changing GCC.  Because the crucial fact about
the planned release is that, without changes, it doesn't work on that
machine.

To make GCC work on that machine, I would need to install new
configuration files.  That is not out of the question, since it is
safe--it certainly won't break any other machines that already work.
But you will have to rush me the legal papers to give the FSF
permission to use such a large piece of text.

* Look for recommendations for your system.

You can find these recommendations in the Installation node of the
manual, and in the file INSTALL.  (These two files have the same text.)

These files say which configuration name to use for your machine, so
use the ones that are recommended.  If you guess, you might guess
wrong and encounter spurious difficulties.  What's more, if you don't
follow the recommendations then you aren't helping to test that its
recommendations are valid.

These files may describe other things that you need to do to make GCC
work on your machine.  If so, you should follow these recommendations
also, for the same reason.

* Don't delay sending information.

When you test on a system and encounter no problems, please tell me
about it right away.  That way, I will know that someone has tested
GCC on that kind of system.

Please don't wait for several days "to see if it really works before
you say anything."  Tell me right away that GCC seems basically to
work; then, if you notice a problem a few days later, tell me
immediately about that when you see it.

It is okay if you double check things before reporting a problem, such
as to see if you can easily fix it.  But don't wait very long.  A good
rule to use in pretesting is always to tell me about every problem on
the same day you encounter it, even if that means you can't find a
solution before you report the problem.

I'd much rather hear about a problem today and a solution tomorrow
than get both of them tomorrow at the same time.

* Make each bug report self-contained.

If you refer back to another message, whether from you or from someone
else, then it will be necessary for anyone who wants to investigate
the bug to find the other message.  This may be difficult, it is
probably time-consuming.

To help me save time, simply copy the relevant parts of any previous
messages into your own bug report.

In particular, if I ask you for more information because a bug report
was incomplete, it is best to send me the *entire* collection of
relevant information, all together.  If you send just the additional
information, that makes me do extra work.  There is even a risk that
I won't remember what question you are sending me the answer to.

* Always be precise when talking about changes you have made.  Show
things rather than describing them.  Use exact filenames (relative to
the main directory of the distribution), not partial ones.  For
example, say "I changed Makefile" rather than "I changed the
makefile".  Instead of saying "I defined the MUMBLE macro", send a
diff.

* Always use `diff -c' to make diffs.  If you don't include context, it
may be hard for me to figure out where you propose to make the
changes.  So I might have to ignore your patch.

* When you write a fix, keep in mind that I can't install a change
that *might* break other systems without the risk that it will fail to
work and therefore require an additional cycle of pretesting.

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 GCC for almost all users.  I can't possibly make a change like
that.  All I can do is send it back to you and ask you to find a fix
that is safe to install.

Sometimes people send fixes that *might* be an improvement in
general--but it is hard to be sure of this.  I can install such
changes some of the time, but not during pretest, when I am trying to
get a new version to work reliably as quickly as possible.

The safest changes for me to install are changes to the configuration
files for a particular machine.  At least I know those can't create
bugs on other machines.

* Don't try changing GCC unless it fails to work if you don't change it.

* In some cases, if you don't follow these guidelines, your
information might still be useful, but I might have to do more work to
make use of it.  Unfortunately, I am so far behind in my work that I
just can't get the job done unless you help me to do it efficiently.

Local Variables:
mode: text
End:

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.