Reporting a Bug in the Toolchain

If you have received an message like:

rgetz@imhotep:~/blackfin/trunk/uClinux-dist> make
  CC      archival/bbunzip.o
/home/rgetz/blackfin/trunk/uClinux-dist/user/busybox/busybox-1.11.1/archival/bbunzip.c: In function ‘bbunpack’:
/home/rgetz/blackfin/trunk/uClinux-dist/user/busybox/busybox-1.11.1/archival/bbunzip.c:120: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://blackfin.uclinux.org/gf/project/toolchain> for instructions.
make[7]: *** [archival/bbunzip.o] Error 1
make[6]: *** [archival] Error 2
make[5]: *** [_all] Error 2
make[4]: *** [all] Error 2
make[4]: Leaving directory `/home/rgetz/blackfin/trunk/uClinux-dist/user/busybox/build-busybox-1.11.1'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/home/rgetz/blackfin/trunk/uClinux-dist/user/busybox'                                                                                             '
make[2]: *** [busybox] Error 2
make[2]: Leaving directory `/home/rgetz/blackfin/trunk/uClinux-dist/user'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/home/rgetz/blackfin/trunk/uClinux-dist/user'
make: *** [subdirs] Error 1%%
rgetz@imhotep:~/blackfin/trunk/uClinux-dist>

You have found the right place.

Just follow these simple steps:

1. Read the process we follow to report a bug.
2. If you still feel that you have a bug, please include the following information:
   • the exact version of GCC;
   • the system type;
   • the options given when GCC was configured/built;
   • the complete command line that triggers the bug;
   • the compiler output (error messages, warnings, etc.); and
   • the preprocessed file (*.i*) that triggers the bug, generated by adding -save-temps to the complete compilation command.
3. Review the bug report to make sure it does not include:
   • A source file that #includes header files that are left out of the bug report (see above)
   • A code snippet that won't cause the compiler to produce the exact output mentioned in the bug report (e.g., a snippet with just a few lines around the one that apparently triggers the bug, with some pieces replaced with ellipses or comments for extra obfuscation)
   • The location (URL) of the package that failed to build (we won't download it, anyway, since you've already given us what we need to duplicate the bug, haven't you?)
   • An error that occurs only some of the times a certain file is compiled, such that retrying a sufficient number of times results in a successful compilation; this is a symptom of a hardware problem, not of a compiler bug (sorry)
   • Assembly files (*.s) produced by the compiler, or any binary files, such as object files, executables, core files, or precompiled header files
   • Duplicate bug reports, or reports of bugs already fixed in the development tree
   • Questions about the correctness or the expected behavior of certain constructs that are not GCC extensions. Ask them in the forum - first read the process for asking questions to make sure you get a quick answer.

In general, all the information we need can be obtained by collecting the command line below, as well as its output and the preprocessed file it generates.

</xterm>rgetz@imhotep:~/blackfin/trunk/uClinux-dist> gcc -v -save-temps all-your-options source-file</xterm>

The only excuses to not send us the preprocessed sources are:

• if you've found a bug in the preprocessor,
• if you've reduced the testcase to a small file that doesn't include any other file or
• if the bug appears only when using precompiled headers (see below)

If you can't post the preprocessed sources because they're proprietary code, then try to create a small file that triggers the same problem.

Since we're supposed to be able to re-create the assembly output (extension .s), you usually should not include it in the bug report, although you may want to post parts of it to point out assembly code you consider to be wrong.

Please avoid posting an archive (.tar, .shar or .zip); we generally need just a single file to reproduce the bug (the .i/.ii/.f preprocessed file), and, by storing it in an archive, you're just making our job harder. Only when your bug report requires multiple source files to be reproduced should you use an archive. This is, for example, the case if you are using INCLUDE directives in Fortran code, which are not processed by the preprocessor, but the compiler. In that case, we need the main file and all INCLUDEd files. In any case, make sure the compiler version, error message, etc, are included in the body of your bug report as plain text, even if needlessly duplicated as part of an archive.

If you're encountering a bug when using a precompiled header, the first thing to do is to delete the precompiled header, and try running the same GCC command again. If the bug happens again, the bug doesn't really involve precompiled headers, please report it without using them by following the instructions above.

If you've found a bug while building a precompiled header (for instance, the compiler crashes), follow the usual instructions above.

If you've found a real precompiled header bug, what we'll need to reproduce it is the sources to build the precompiled header (as a single .i file), the source file that uses the precompiled header, any other headers that source file includes, and the command lines that you used to build the precompiled header and to use it.

Please don't send us the actual precompiled header. It is likely to be very large and we can't use it to reproduce the problem.

Most of the content on this page is from http://gcc.gnu.org/bugs.html. It is included here since you SHOULD NOT report blackfin toolchain bugs to the mainline gcc project, but do them on this forum.