| 1 |
|
|---|
| 2 | GCC Bugs
|
|---|
| 3 |
|
|---|
| 4 | The latest version of this document is always available at
|
|---|
| 5 | [1]http://www.gnu.org/software/gcc/bugs.html.
|
|---|
| 6 | _________________________________________________________________
|
|---|
| 7 |
|
|---|
| 8 | Table of Contents
|
|---|
| 9 |
|
|---|
| 10 | * [2]Reporting Bugs
|
|---|
| 11 | + [3]What we need
|
|---|
| 12 | + [4]What we DON'T want
|
|---|
| 13 | + [5]Where to post it
|
|---|
| 14 | + [6]Detailed bug reporting instructions
|
|---|
| 15 | + [7]Detailed bug reporting instructions for GNAT
|
|---|
| 16 | + [8]Detailed bug reporting instructions when using a
|
|---|
| 17 | precompiled header
|
|---|
| 18 | * [9]Managing Bugs (GNATS and the test-suite)
|
|---|
| 19 | * [10]Frequently Reported Bugs in GCC
|
|---|
| 20 | + [11]General
|
|---|
| 21 | + [12]Fortran
|
|---|
| 22 | + [13]C
|
|---|
| 23 | + [14]C++
|
|---|
| 24 | o [15]Common problems updating from G++ 2.95 to G++ 3.0
|
|---|
| 25 | o [16]Non-bugs
|
|---|
| 26 | o [17]Missing features
|
|---|
| 27 | o [18]Parse errors for "simple" code
|
|---|
| 28 | o [19]Optimization at -O3 takes a very long time
|
|---|
| 29 | _________________________________________________________________
|
|---|
| 30 |
|
|---|
| 31 | Reporting Bugs
|
|---|
| 32 |
|
|---|
| 33 | Our preferred way of receiving bugs is via the [20]GCC GNATS bug
|
|---|
| 34 | reporting system.
|
|---|
| 35 |
|
|---|
| 36 | Before you report a bug, please check the [21]list of well-known bugs
|
|---|
| 37 | and, if possible in any way, try a current development snapshot. If
|
|---|
| 38 | you want to report a bug with versions of GCC before 3.1 we strongly
|
|---|
| 39 | recommend upgrading to the current release first.
|
|---|
| 40 |
|
|---|
| 41 | Before reporting that GCC compiles your code incorrectly, please
|
|---|
| 42 | compile it with gcc -Wall and see whether this shows anything wrong
|
|---|
| 43 | with your code that could be the cause instead of a bug in GCC.
|
|---|
| 44 |
|
|---|
| 45 | Summarized bug reporting instructions
|
|---|
| 46 |
|
|---|
| 47 | After this summary, you'll find detailed bug reporting instructions,
|
|---|
| 48 | that explain how to obtain some of the information requested in this
|
|---|
| 49 | summary.
|
|---|
| 50 |
|
|---|
| 51 | What we need
|
|---|
| 52 |
|
|---|
| 53 | Please include in your bug report all of the following items, the
|
|---|
| 54 | first three of which can be obtained from the output of gcc -v:
|
|---|
| 55 | * the exact version of GCC;
|
|---|
| 56 | * the system type;
|
|---|
| 57 | * the options given when GCC was configured/built;
|
|---|
| 58 | * the complete command line that triggers the bug;
|
|---|
| 59 | * the compiler output (error messages, warnings, etc.); and
|
|---|
| 60 | * the preprocessed file (*.i*) that triggers the bug, generated by
|
|---|
| 61 | adding -save-temps to the complete compilation command, or, in the
|
|---|
| 62 | case of a bug report for the GNAT front end, a complete set of
|
|---|
| 63 | source files (see below).
|
|---|
| 64 |
|
|---|
| 65 | What we do not want
|
|---|
| 66 |
|
|---|
| 67 | * A source file that #includes header files that are left out of the
|
|---|
| 68 | bug report (see above)
|
|---|
| 69 | * That source file and a collection of header files.
|
|---|
| 70 | * An attached archive (tar, zip, shar, whatever) containing all (or
|
|---|
| 71 | some :-) of the above.
|
|---|
| 72 | * A code snippet that won't cause the compiler to produce the exact
|
|---|
| 73 | output mentioned in the bug report (e.g., a snippet with just a
|
|---|
| 74 | few lines around the one that apparently triggers the bug, with
|
|---|
| 75 | some pieces replaced with ellipses or comments for extra
|
|---|
| 76 | obfuscation :-)
|
|---|
| 77 | * The location (URL) of the package that failed to build (we won't
|
|---|
| 78 | download it, anyway, since you've already given us what we need to
|
|---|
| 79 | duplicate the bug, haven't you? :-)
|
|---|
| 80 | * An error that occurs only some of the times a certain file is
|
|---|
| 81 | compiled, such that retrying a sufficient number of times results
|
|---|
| 82 | in a successful compilation; this is a symptom of a hardware
|
|---|
| 83 | problem, not of a compiler bug (sorry)
|
|---|
| 84 | * E-mail messages that complement previous, incomplete bug reports.
|
|---|
| 85 | Post a new, self-contained, full bug report instead, if possible
|
|---|
| 86 | as a follow-up to the original bug report
|
|---|
| 87 | * Assembly files (*.s) produced by the compiler, or any binary
|
|---|
| 88 | files, such as object files, executables, core files, or
|
|---|
| 89 | precompiled header files
|
|---|
| 90 | * Duplicate bug reports, or reports of bugs already fixed in the
|
|---|
| 91 | development tree, especially those that have already been reported
|
|---|
| 92 | as fixed last week :-)
|
|---|
| 93 | * Bugs in the assembler, the linker or the C library. These are
|
|---|
| 94 | separate projects, with separate mailing lists and different bug
|
|---|
| 95 | reporting procedures
|
|---|
| 96 | * Bugs in releases or snapshots of GCC not issued by the GNU
|
|---|
| 97 | Project. Report them to whoever provided you with the release
|
|---|
| 98 | * Questions about the correctness or the expected behavior of
|
|---|
| 99 | certain constructs that are not GCC extensions. Ask them in forums
|
|---|
| 100 | dedicated to the discussion of the programming language
|
|---|
| 101 |
|
|---|
| 102 | Where to post it
|
|---|
| 103 |
|
|---|
| 104 | Please submit your bug report directly to the [22]GCC GNATS bug
|
|---|
| 105 | database. Only if this is not possible, mail all information to
|
|---|
| 106 | [23][email protected] or [24][email protected].
|
|---|
| 107 |
|
|---|
| 108 | The GCC lists have message size limits (200 kbytes) and bug reports
|
|---|
| 109 | over those limits will currently be bounced. If your bug is larger
|
|---|
| 110 | than that, please post it using the [25]GCC GNATS bug database.
|
|---|
| 111 |
|
|---|
| 112 | Detailed bug reporting instructions
|
|---|
| 113 |
|
|---|
| 114 | Please refer to the [26]next section when reporting bugs in GNAT, the
|
|---|
| 115 | Ada compiler, or to the [27]one after that when reporting bugs that
|
|---|
| 116 | appear when using a precompiled header.
|
|---|
| 117 |
|
|---|
| 118 | In general, all the information we need can be obtained by collecting
|
|---|
| 119 | the command line below, as well as its output and the preprocessed
|
|---|
| 120 | file it generates.
|
|---|
| 121 |
|
|---|
| 122 | gcc -v -save-temps all-your-options source-file
|
|---|
| 123 |
|
|---|
| 124 | Typically the preprocessed file (extension .i for C or .ii for C++)
|
|---|
| 125 | will be large, so please compress the resulting file with one of the
|
|---|
| 126 | popular compression programs such as bzip2, gzip, zip or compress (in
|
|---|
| 127 | decreasing order of preference). Use maximum compression (-9) if
|
|---|
| 128 | available. Please include the compressed preprocessor output in your
|
|---|
| 129 | bug report, even if the source code is freely available elsewhere; it
|
|---|
| 130 | makes the job of our volunteer testers much easier.
|
|---|
| 131 |
|
|---|
| 132 | The only excuses to not send us the preprocessed sources are (i) if
|
|---|
| 133 | you've found a bug in the preprocessor, (ii) if you've reduced the
|
|---|
| 134 | testcase to a small file that doesn't include any other file or (iii)
|
|---|
| 135 | if the bug appears only when using precompiled headers. If you can't
|
|---|
| 136 | post the preprocessed sources because they're proprietary code, then
|
|---|
| 137 | try to create a small file that triggers the same problem.
|
|---|
| 138 |
|
|---|
| 139 | Since we're supposed to be able to re-create the assembly output
|
|---|
| 140 | (extension .s), you usually should not include it in the bug report,
|
|---|
| 141 | although you may want to post parts of it to point out assembly code
|
|---|
| 142 | you consider to be wrong.
|
|---|
| 143 |
|
|---|
| 144 | Whether to use MIME attachments or uuencode is up to you. In any case,
|
|---|
| 145 | make sure the compiler command line, version and error output are in
|
|---|
| 146 | plain text, so that we don't have to decode the bug report in order to
|
|---|
| 147 | tell who should take care of it. A meaningful subject indicating
|
|---|
| 148 | language and platform also helps.
|
|---|
| 149 |
|
|---|
| 150 | Please avoid posting an archive (.tar, .shar or .zip); we generally
|
|---|
| 151 | need just a single file to reproduce the bug (the .i/.ii preprocessed
|
|---|
| 152 | file), and, by storing it in an archive, you're just making our
|
|---|
| 153 | volunteers' jobs harder. Only when your bug report requires multiple
|
|---|
| 154 | source files to be reproduced should you use an archive. In any case,
|
|---|
| 155 | make sure the compiler version, error message, etc, are included in
|
|---|
| 156 | the body of your bug report as plain text, even if needlessly
|
|---|
| 157 | duplicated as part of an archive.
|
|---|
| 158 |
|
|---|
| 159 | If you fail to supply enough information for a bug report to be
|
|---|
| 160 | reproduced, someone will probably ask you to post additional
|
|---|
| 161 | information (or just ignore your bug report, if they're in a bad day,
|
|---|
| 162 | so try to get it right on the first posting :-). In this case, please
|
|---|
| 163 | post the additional information to the bug reporting mailing list, not
|
|---|
| 164 | just to the person who requested it, unless explicitly told so. If
|
|---|
| 165 | possible, please include in this follow-up all the information you had
|
|---|
| 166 | supplied in the incomplete bug report (including the preprocessor
|
|---|
| 167 | output), so that the new bug report is self-contained.
|
|---|
| 168 |
|
|---|
| 169 | Detailed bug reporting instructions for GNAT
|
|---|
| 170 |
|
|---|
| 171 | See the [28]previous section for bug reporting instructions for GCC
|
|---|
| 172 | language implementations other than Ada.
|
|---|
| 173 |
|
|---|
| 174 | Bug reports have to contain at least the following information in
|
|---|
| 175 | order to be useful:
|
|---|
| 176 | * the exact version of GCC, as shown by "gcc -v";
|
|---|
| 177 | * the system type;
|
|---|
| 178 | * the options when GCC was configured/built;
|
|---|
| 179 | * the exact command line passed to the gcc program triggering the
|
|---|
| 180 | bug (not just the flags passed to gnatmake, but gnatmake prints
|
|---|
| 181 | the parameters it passed to gcc)
|
|---|
| 182 | * a collection of source files for reproducing the bug, preferably a
|
|---|
| 183 | minimal set (see below);
|
|---|
| 184 | * a description of the expected behavior;
|
|---|
| 185 | * a description of actual behavior.
|
|---|
| 186 |
|
|---|
| 187 | If your code depends on additional source files (usually package
|
|---|
| 188 | specifications), submit the source code for these compilation units in
|
|---|
| 189 | a single file that is acceptable input to gnatchop, i.e. contains no
|
|---|
| 190 | non-Ada text. If the compilation terminated normally, you can usually
|
|---|
| 191 | obtain a list of dependencies using the "gnatls -d main_unit" command,
|
|---|
| 192 | where main_unit is the file name of the main compilation unit (which
|
|---|
| 193 | is also passed to gcc).
|
|---|
|
|---|
