Contents

Reporting GCC bugs

We need at least three things in a bug report against GCC:

a testcase

a testcase

a testcase

Testcase

A testcase is something short. It's not go to that site, download this tarball, compile, see error.
A good testcase consists of just one self-contained file. Think about this, one file.
This means, no includes. Hence it has to be preprocessed. Preprocess with:

gcc -E [other options ...] source.c > source.i

Or use -save-temps. C++ preprocessed files are named source.ii.

Furthermore, it needs to be short. It should contain only the source which is necessary to
show the error. No additional functions or declarations. Delete all non-essential blocks. Start by
deleting whole functions, then top-level declarations, then simplify the function in which the error
occurs. Delete non-essential members from structures or classes, this might need code changes. It's
good as long as it still shows the error. Remember that only necessary functions are compiled.
A static function which never is used is not compiled with newer GCCs. Hence you might want to
make functions non-static.

Anything larger than 200 lines is probably too large. A bug report with 100 lines is better. Anything containing more
than three functions probably is not as reduced as much as it could be. Try harder. It takes time to reduce,
but if you don't do it, we have to do it, and we are already the bottleneck in this. This means that we might not
look at your bug report very enthusiastically if it's too large.

General advice

Like all good bug reports it should follow basically this style:

When compiling this:
<source code> or mention an attachment
with this command:
% gcc [your options] bla.i
this happens:
<outcome>
with this system:
<gcc -v output>
<uname -a output>
I instead expect this to happen:
<expected outcome>
because of <reason why you think so>.

Sometimes the expected outcome is obvious and should not be mentioned. E.g. if you report an
internal compiler error, the expected outcome of course is, that this ICE does not happen. No need
to mention that. If you suspect a miscompilation, design the testcase as runtime test, which has
some visible effect (e.g. calling abort when the wrong result is calculated, or printing the result,
saying which you would expect).

Please paste the exact command lines you use, paste the -v output, and the uname -a output. We don't want
compile with -O2, i.e. descriptions in your words, when it is perfectly fine and more exact to
say compile with# gcc -c -O2 -fPIC -funny-options bla.i, where the command is copy-pasted
as is from a terminal.

Don't forget the system details. Have I mentioned that we need a testcase?

Nice to have

We use compilers which usually have changes on top of the FSF GCC. But it's still often the case
that the FSF GCC shows exactly the same error. If you are in a position to verify this, then please
do so, and report the bug directly to the bugzilla of GCC.