Bugs:Reporting GCC Bugs

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.

Also, please see http://gcc.gnu.org/bugs.html for more information how to write a good bug report for GCC.