blob: dc93e3f71520b993fc9906d02c8bf3ee760d3454 [file] [log] [blame]
Reporting bugs in stbgcc
Before reporting a bug, please
- Check that the behaviour really is a bug. Have a look into some
ANSI standards document.
- Check the list of well known bugs:
- Try to reproduce the bug with the latest stbgcc release.
- Try to find out if the bug is a regression (an older stbgcc version
does not show the bug).
- Check if the bug is already reported in the bug tracking systems.
Where to report a bug
Please report bugs found in the packaging of stbgcc to Broadcom. See below
how issues should be reported.
If you think you have found an upstream bug, you did check the section
above ("Before reporting a bug") and are able to provide a complete bug
report (see below "How to report a bug"), then you may help the stbgcc
maintainers, if you report the bug upstream and then submit a bug
report and tell us the upstream report number.
If in doubt, just report it to Broadcom.
Report the issue at .
Broadcom-internal users should report the issue for the 'toolchain'
component at .
How to report a bug
The main purpose of a bug report is to enable us to fix the bug. The
most important prerequisite for this is that the report must be
complete and self-contained, which we explain in detail below.
Before you report a bug, please check the list of well-known bugs and,
if possible in any way, try the latest stbgcc release.
Summarized bug reporting instructions
What we need
Please include in your bug report all of the following items:
* the exact version of stbgcc;
* the complete command line that triggers the bug;
* the output (error messages, warnings, etc.);
* a self-contained testcase allowing us to reproduce the issue. This
could be:
* (gcc bugs) the preprocessed file (*.i*) that triggers the bug,
generated by adding -save-temps to the complete compilation
* (all bugs) a complete set of source files that can be used to
reproduce the issue
What we do not want
* A source file that #includes header files that are left out
of the bug report (see above)
* That source file and a collection of header files.
* An attached archive (tar, zip, shar, whatever) containing all
(or some :-) of the 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