| 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: http://gcc.gnu.org/bugs.html#known |
| |
| - 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. |
| |
| Broadcom: http://jira.broadcom.com/browse/SWLINUX/component/10700 |
| Linaro: https://bugs.linaro.org/ |
| Upstream: http://gcc.gnu.org/bugzilla/ |
| https://sourceware.org/bugzilla/ |
| |
| 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 http://support.broadcom.com/ . |
| Broadcom-internal users should report the issue for the 'toolchain' |
| component at http://jira.broadcom.com/browse/SWLINUX . |
| |
| |
| 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 |
| command. |
| * (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 |
