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