| 1 | <html>
|
|---|
| 2 |
|
|---|
| 3 | <head>
|
|---|
| 4 | <title>GCC Bugs</title>
|
|---|
| 5 | </head>
|
|---|
| 6 |
|
|---|
| 7 | <body>
|
|---|
| 8 | <h1>GCC Bugs</h1>
|
|---|
| 9 |
|
|---|
| 10 | <p>The latest version of this document is always available at
|
|---|
| 11 | <a href="http://www.gnu.org/software/gcc/bugs.html">http://www.gnu.org/software/gcc/bugs.html</a>.</p>
|
|---|
| 12 |
|
|---|
| 13 | <hr />
|
|---|
| 14 |
|
|---|
| 15 | <h2>Table of Contents</h2>
|
|---|
| 16 | <ul>
|
|---|
| 17 | <li><a href="#report">Reporting Bugs</a>
|
|---|
| 18 | <ul>
|
|---|
| 19 | <li><a href="#need">What we need</a></li>
|
|---|
| 20 | <li><a href="#dontwant">What we DON'T want</a></li>
|
|---|
| 21 | <li><a href="#where">Where to post it</a></li>
|
|---|
| 22 | <li><a href="#detailed">Detailed bug reporting instructions</a></li>
|
|---|
| 23 | <li><a href="#gnat">Detailed bug reporting instructions for GNAT</a></li>
|
|---|
| 24 | <li><a href="#pch">Detailed bug reporting instructions when using a precompiled header</a></li>
|
|---|
| 25 | </ul>
|
|---|
| 26 | </li>
|
|---|
| 27 | <li><a href="#manage">Managing Bugs (GNATS and the test-suite)</a></li>
|
|---|
| 28 | <li><a href="#known">Frequently Reported Bugs in GCC</a>
|
|---|
| 29 | <ul>
|
|---|
| 30 | <li><a href="#general">General</a></li>
|
|---|
| 31 | <li><a href="#fortran">Fortran</a></li>
|
|---|
| 32 | <li><a href="#c">C</a></li>
|
|---|
| 33 | <li><a href="#cplusplus">C++</a>
|
|---|
| 34 | <ul>
|
|---|
| 35 | <li><a href="#updating">Common problems updating from G++ 2.95 to
|
|---|
| 36 | G++ 3.0</a></li>
|
|---|
| 37 | <li><a href="#nonbugs">Non-bugs</a></li>
|
|---|
| 38 | <li><a href="#missing">Missing features</a></li>
|
|---|
| 39 | <li><a href="#parsing">Parse errors for "simple" code</a></li>
|
|---|
| 40 | <li><a href="#-O3">Optimization at <code>-O3</code> takes a
|
|---|
| 41 | very long time</a></li>
|
|---|
| 42 | </ul>
|
|---|
| 43 | </li>
|
|---|
| 44 | </ul>
|
|---|
| 45 | </li>
|
|---|
| 46 | </ul>
|
|---|
| 47 |
|
|---|
| 48 | <hr />
|
|---|
| 49 |
|
|---|
| 50 | <h1><a name="report">Reporting Bugs</a></h1>
|
|---|
| 51 |
|
|---|
| 52 | <p>Our preferred way of receiving bugs is via the
|
|---|
| 53 | <a href="gnats.html">GCC GNATS bug reporting system</a>.</p>
|
|---|
| 54 |
|
|---|
| 55 | <p>Before you report a bug, please check the
|
|---|
| 56 | <a href="#known">list of well-known bugs</a> and, <strong>if possible
|
|---|
| 57 | in any way, try a current development snapshot</strong>.
|
|---|
| 58 | If you want to report a bug with versions of GCC before 3.1 we strongly
|
|---|
| 59 | recommend upgrading to the current release first.</p>
|
|---|
| 60 |
|
|---|
| 61 | <p>Before reporting that GCC compiles your code incorrectly, please
|
|---|
| 62 | compile it with <code>gcc -Wall</code> and see whether this shows
|
|---|
| 63 | anything wrong with your code that could be the cause instead of a bug
|
|---|
| 64 | in GCC.</p>
|
|---|
| 65 |
|
|---|
| 66 | <h2>Summarized bug reporting instructions</h2>
|
|---|
| 67 |
|
|---|
| 68 | <p>After this summary, you'll find detailed bug reporting
|
|---|
| 69 | instructions, that explain how to obtain some of the information
|
|---|
| 70 | requested in this summary.</p>
|
|---|
| 71 |
|
|---|
| 72 | <h3><a name="need">What we need</a></h3>
|
|---|
| 73 |
|
|---|
| 74 | Please include in your bug report all of the following items, the first
|
|---|
| 75 | three of which can be obtained from the output of <code>gcc -v</code>:
|
|---|
| 76 |
|
|---|
| 77 | <ul>
|
|---|
| 78 | <li>the exact version of GCC;</li>
|
|---|
| 79 | <li>the system type;</li>
|
|---|
| 80 | <li>the options given when GCC was configured/built;</li>
|
|---|
| 81 | <li>the complete command line that triggers the bug;</li>
|
|---|
| 82 | <li>the compiler output (error messages, warnings, etc.); and</li>
|
|---|
| 83 | <li>the <em>preprocessed</em> file (<code>*.i*</code>) that triggers the
|
|---|
| 84 | bug, generated by adding <code>-save-temps</code> to the complete
|
|---|
| 85 | compilation command, or, in the case of a bug report for the GNAT front end,
|
|---|
| 86 | a complete set of source files (see below).</li>
|
|---|
| 87 | </ul>
|
|---|
| 88 |
|
|---|
| 89 | <h3><a name="dontwant">What we do <strong>not</strong> want</a></h3>
|
|---|
| 90 |
|
|---|
| 91 | <ul>
|
|---|
| 92 | <li>A source file that <code>#include</code>s header files that are left
|
|---|
| 93 | out of the bug report (see above)</li>
|
|---|
| 94 |
|
|---|
| 95 | <li>That source file and a collection of header files.</li>
|
|---|
| 96 |
|
|---|
| 97 | <li>An attached archive (tar, zip, shar, whatever) containing all
|
|---|
| 98 | (or some :-) of the above.</li>
|
|---|
| 99 |
|
|---|
| 100 | <li>A code snippet that won't cause the compiler to produce the
|
|---|
| 101 | exact output mentioned in the bug report (e.g., a snippet with just
|
|---|
| 102 | a few lines around the one that <b>apparently</b> triggers the bug,
|
|---|
| 103 | with some pieces replaced with ellipses or comments for extra
|
|---|
| 104 | obfuscation :-)</li>
|
|---|
| 105 |
|
|---|
| 106 | <li>The location (URL) of the package that failed to build (we won't
|
|---|
| 107 | download it, anyway, since you've already given us what we need to
|
|---|
| 108 | duplicate the bug, haven't you? :-)</li>
|
|---|
| 109 |
|
|---|
| 110 | <li>An error that occurs only some of the times a certain file is
|
|---|
| 111 | compiled, such that retrying a sufficient number of times results in
|
|---|
| 112 | a successful compilation; this is a symptom of a hardware problem,
|
|---|
| 113 | not of a compiler bug (sorry)</li>
|
|---|
| 114 |
|
|---|
| 115 | <li>E-mail messages that complement previous, incomplete bug
|
|---|
| 116 | reports. Post a new, self-contained, full bug report instead, if
|
|---|
| 117 | possible as a follow-up to the original bug report</li>
|
|---|
| 118 |
|
|---|
| 119 | <li>Assembly files (<code>*.s</code>) produced by the compiler, or any
|
|---|
| 120 | binary files, such as object files, executables, core files, or
|
|---|
| 121 | precompiled header files</li>
|
|---|
| 122 |
|
|---|
| 123 | <li>Duplicate bug reports, or reports of bugs already fixed in the
|
|---|
| 124 | development tree, especially those that have already been reported
|
|---|
| 125 | as fixed last week :-)</li>
|
|---|
| 126 |
|
|---|
| 127 | <li>Bugs in the assembler, the linker or the C library. These are
|
|---|
| 128 | separate projects, with separate mailing lists and different bug
|
|---|
| 129 | reporting procedures</li>
|
|---|
| 130 |
|
|---|
| 131 | <li>Bugs in releases or snapshots of GCC not issued by the GNU
|
|---|
| 132 | Project. Report them to whoever provided you with the release</li>
|
|---|
| 133 |
|
|---|
| 134 | <li>Questions about the correctness or the expected behavior of
|
|---|
| 135 | certain constructs that are not GCC extensions. Ask them in forums
|
|---|
| 136 | dedicated to the discussion of the programming language</li>
|
|---|
| 137 | </ul>
|
|---|
| 138 |
|
|---|
| 139 | <h3><a name="where">Where to post it</a></h3>
|
|---|
| 140 |
|
|---|
| 141 | <p>Please submit your bug report directly to the
|
|---|
| 142 | <a href="gnats.html">GCC GNATS bug database</a>.
|
|---|
| 143 | Only if this is not possible, mail all information to
|
|---|
| 144 | <a href="mailto:bug-gcc@gnu.org">bug-gcc@gnu.org</a> or
|
|---|
| 145 | <a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a>.</p>
|
|---|
| 146 |
|
|---|
| 147 | <p>The GCC lists have message size limits (200 kbytes) and bug reports
|
|---|
| 148 | over those limits will currently be bounced. If your bug is larger
|
|---|
| 149 | than that, please post it using the <a href="gnats.html">GCC GNATS bug
|
|---|
| 150 | database</a>.</p>
|
|---|
| 151 |
|
|---|
| 152 | <h2><a name="detailed">Detailed bug reporting instructions</a></h2>
|
|---|
| 153 |
|
|---|
| 154 | <p>Please refer to the <a href="#gnat">next section</a> when reporting
|
|---|
| 155 | bugs in GNAT, the Ada compiler, or to the <a href="#pch">one after
|
|---|
| 156 | that</a> when reporting bugs that appear when using a precompiled header.</p>
|
|---|
| 157 |
|
|---|
| 158 | <p>In general, all the information we need can be obtained by
|
|---|
| 159 | collecting the command line below, as well as its output and the
|
|---|
| 160 | preprocessed file it generates.</p>
|
|---|
| 161 |
|
|---|
| 162 | <blockquote><code>gcc -v -save-temps <i>all-your-options
|
|---|
| 163 | source-file</i></code></blockquote>
|
|---|
| 164 |
|
|---|
| 165 | <p>Typically the preprocessed file (extension <code>.i</code> for C or
|
|---|
| 166 | <code>.ii</code> for C++) will be large, so please compress the
|
|---|
| 167 | resulting file with one of the popular compression programs such as
|
|---|
| 168 | bzip2, gzip, zip or compress (in
|
|---|
| 169 | decreasing order of preference). Use maximum compression
|
|---|
| 170 | (<code>-9</code>) if available. Please include the compressed
|
|---|
| 171 | preprocessor output in your bug report, even if the source code is
|
|---|
| 172 | freely available elsewhere; it makes the job of our volunteer testers
|
|---|
| 173 | much easier.</p>
|
|---|
| 174 |
|
|---|
| 175 | <p>The <b>only</b> excuses to not send us the preprocessed sources are
|
|---|
| 176 | (i) if you've found a bug in the preprocessor, (ii) if you've reduced
|
|---|
| 177 | the testcase to a small file that doesn't include any other file or
|
|---|
| 178 | (iii) if the bug appears only when using precompiled headers. If you
|
|---|
| 179 | can't post the preprocessed sources because they're proprietary code,
|
|---|
| 180 | then try to create a small file that triggers the same problem.</p>
|
|---|
| 181 |
|
|---|
| 182 | <p>Since we're supposed to be able to re-create the assembly output
|
|---|
| 183 | (extension <code>.s</code>), you usually should not include
|
|---|
| 184 | it in the bug report, although you may want to post parts of it to
|
|---|
| 185 | point out assembly code you consider to be wrong.</p>
|
|---|
| 186 |
|
|---|
| 187 | <p>Whether to use MIME attachments or <code>uuencode</code> is up to
|
|---|
| 188 | you. In any case, make sure the compiler command line, version and
|
|---|
| 189 | error output are in plain text, so that we don't have to decode the
|
|---|
| 190 | bug report in order to tell who should take care of it. A meaningful
|
|---|
| 191 | subject indicating language and platform also helps.</p>
|
|---|
| 192 |
|
|---|
| 193 | <p>Please avoid posting an archive (.tar, .shar or .zip); we generally
|
|---|
| 194 | need just a single file to reproduce the bug (the .i/.ii preprocessed
|
|---|
| 195 | file), and, by storing it in an archive, you're just making our
|
|---|
| 196 | volunteers' jobs harder. Only when your bug report requires multiple
|
|---|
| 197 | source files to be reproduced should you use an archive. In any case,
|
|---|
| 198 | make sure the compiler version, error message, etc, are included in
|
|---|
| 199 | the body of your bug report as plain text, even if needlessly
|
|---|
| 200 | duplicated as part of an archive.</p>
|
|---|
| 201 |
|
|---|
| 202 | <p>If you fail to supply enough information for a bug report to be
|
|---|
| 203 | reproduced, someone will probably ask you to post additional
|
|---|
| 204 | information (or just ignore your bug report, if they're in a bad day,
|
|---|
| 205 | so try to get it right on the first posting :-). In this case, please
|
|---|
| 206 | post the additional information to the bug reporting mailing list, not
|
|---|
| 207 | just to the person who requested it, unless explicitly told so. If
|
|---|
| 208 | possible, please include in this follow-up all the information you had
|
|---|
| 209 | supplied in the incomplete bug report (including the preprocessor
|
|---|
| 210 | output), so that the new bug report is self-contained.</p>
|
|---|
| 211 |
|
|---|
| 212 | <h2><a name="gnat">Detailed bug reporting instructions for GNAT</a></h2>
|
|---|
| 213 |
|
|---|
| 214 | <p>See the <a href="#detailed">previous section</a> for bug reporting
|
|---|
| 215 | instructions for GCC language implementations other than Ada.</p>
|
|---|
| 216 |
|
|---|
| 217 | <p>Bug reports have to contain at least the following information in
|
|---|
| 218 | order to be useful:</p>
|
|---|
| 219 |
|
|---|
| 220 | <ul>
|
|---|
| 221 | <li>the exact version of GCC, as shown by "<code>gcc -v</code>";</li>
|
|---|
| 222 | <li>the system type;</li>
|
|---|
| 223 | <li>the options when GCC was configured/built;</li>
|
|---|
| 224 | <li>the exact command line passed to the <code>gcc</code> program
|
|---|
| 225 | triggering the bug
|
|---|
| 226 | (not just the flags passed to <code>gnatmake</code>, but
|
|---|
| 227 | <code>gnatmake</code> prints the parameters it passed to <code>gcc</code>)</li>
|
|---|
| 228 | <li>a collection of source files for reproducing the bug,
|
|---|
| 229 | preferably a minimal set (see below);</li>
|
|---|
| 230 | <li>a description of the expected behavior;</li>
|
|---|
| 231 | <li>a description of actual behavior.</li>
|
|---|
| 232 | </ul>
|
|---|
| 233 |
|
|---|
| 234 | <p>If your code depends on additional source files (usually package
|
|---|
| 235 | specifications), submit the source code for these compilation units in
|
|---|
| 236 | a single file that is acceptable input to <code>gnatchop</code>,
|
|---|
| 237 | i.e. contains no non-Ada text. If the compilation terminated
|
|---|
| 238 | normally, you can usually obtain a list of dependencies using the
|
|---|
| 239 | "<code>gnatls -d <i>main_unit</i></code>" command, where
|
|---|
| 240 | <code><i>main_unit</i></code> is the file name of the main compilation
|
|---|
| 241 | unit (which is also passed to <code>gcc</code>).</p>
|
|---|
| 242 |
|
|---|
| 243 | <p>If you report a bug which causes the compiler to print a bug box,
|
|---|
| 244 | include that bug box in your report, and do not forget to send all the
|
|---|
| 245 | source files listed after the bug box along with your report.</p>
|
|---|
| 246 |
|
|---|
| 247 | <p>If you use <code>gnatprep</code>, be sure to send in preprocessed
|
|---|
| 248 | sources (unless you have to report a bug in <code>gnatprep</code>).</p>
|
|---|
| 249 |
|
|---|
| 250 | <p>When you have checked that your report meets these criteria, please
|
|---|
| 251 | submit it according to our <a href="#where">generic instructions</a>.
|
|---|
| 252 | (If you use a mailing list for reporting, please include an
|
|---|
| 253 | "<code>[Ada]</code>" tag in the subject.)</p>
|
|---|
| 254 |
|
|---|
| 255 | <h2><a name="pch">Detailed bug reporting instructions when using a
|
|---|
| 256 | precompiled header</a></h2>
|
|---|
| 257 |
|
|---|
| 258 | <p>If you're encountering a bug when using a precompiled header, the
|
|---|
| 259 | first thing to do is to delete the precompiled header, and try running
|
|---|
| 260 | the same GCC command again. If the bug happens again, the bug doesn't
|
|---|
| 261 | really involve precompiled headers, please report it without using
|
|---|
| 262 | them by following the instructions <a href="#detailed">above</a>.</p>
|
|---|
| 263 |
|
|---|
| 264 | <p>If you've found a bug while <i>building</i> a precompiled header
|
|---|
| 265 | (for instance, the compiler crashes), follow the usual instructions
|
|---|
| 266 | <a href="#detailed">above</a>.</p>
|
|---|
| 267 |
|
|---|
| 268 | <p>If you've found a real precompiled header bug, what we'll need to
|
|---|
| 269 | reproduce it is the sources to build the precompiled header (as a
|
|---|
| 270 | single <code>.i</code> file), the source file that uses the
|
|---|
| 271 | precompiled header, any other headers that source file includes, and
|
|---|
| 272 | the command lines that you used to build the precompiled header and to
|
|---|
| 273 | use it.</p>
|
|---|
| 274 |
|
|---|
| 275 | <p>Please <strong>don't</strong> send us the actual precompiled
|
|---|
| 276 | header. It is likely to be very large and we can't use it to
|
|---|
| 277 | reproduce the problem.</p>
|
|---|
| 278 |
|
|---|
| 279 | <h1><a name="manage">Managing Bugs (GNATS and the test-suite)</a></h1>
|
|---|
| 280 |
|
|---|
| 281 | <p>This section contains information mostly intended for GCC
|
|---|
| 282 | contributors.</p>
|
|---|
| 283 |
|
|---|
| 284 | <p>If you find a bug, but you are not fixing it (yet):</p>
|
|---|
| 285 | <ol>
|
|---|
| 286 | <li>Create a (minimal) test-case.</li>
|
|---|
| 287 | <li>Add the test-case to our test-suite, marking it as XFAIL unless
|
|---|
| 288 | the bug is a regression.</li>
|
|---|
| 289 | <li>Add a bug report referencing the test-case to GNATS.</li>
|
|---|
| 290 | </ol>
|
|---|
| 291 |
|
|---|
| 292 | <p>If you fix a bug for which there is already a GNATS entry:</p>
|
|---|
| 293 | <ol>
|
|---|
| 294 | <li>Remove the XFAIL on the test-case.</li>
|
|---|
| 295 | <li>Close the bug report in GNATS.</li>
|
|---|
| 296 | </ol>
|
|---|
| 297 |
|
|---|
| 298 | <p>If you find a bug, and you are fixing it right then:</p>
|
|---|
| 299 | <ol>
|
|---|
| 300 | <li>Create a (minimal) test-case.</li>
|
|---|
| 301 | <li>Add the test-case to our test-suite, marking it as PASS.</li>
|
|---|
| 302 | <li>Check in your fixes.</li>
|
|---|
| 303 | </ol>
|
|---|
| 304 |
|
|---|
| 305 | <hr />
|
|---|
| 306 |
|
|---|
| 307 | <h1><a name="known">Frequently Reported Bugs in GCC</a></h1>
|
|---|
| 308 |
|
|---|
| 309 | <h2><a name="fortran">Fortran</a></h2>
|
|---|
| 310 |
|
|---|
| 311 | <p>Fortran bugs are documented in the G77 manual rather than
|
|---|
| 312 | explicitly listed here. Please see
|
|---|
| 313 | <a href="http://gcc.gnu.org/onlinedocs/g77/Trouble.html">Known Causes of
|
|---|
| 314 | Trouble with GNU Fortran</a> in the G77 manual.</p>
|
|---|
| 315 |
|
|---|
| 316 | <hr />
|
|---|
| 317 |
|
|---|
| 318 | <h2><a name="c">C</a></h2>
|
|---|
| 319 |
|
|---|
| 320 | <p>The following are not bugs in the C compiler, but are reported
|
|---|
| 321 | often enough to warrant a mention here.</p>
|
|---|
| 322 |
|
|---|
| 323 | <dl>
|
|---|
| 324 | <dt>Cannot initialize a static variable with <code>stdin</code>.</dt>
|
|---|
| 325 | <dd><p>This has nothing to do with GCC, but people ask us about it a
|
|---|
| 326 | lot. Code like this:</p>
|
|---|
| 327 |
|
|---|
| 328 | <blockquote><pre>
|
|---|
| 329 | #include <stdio.h>
|
|---|
| 330 |
|
|---|
| 331 | FILE *yyin = stdin;
|
|---|
| 332 | </pre></blockquote>
|
|---|
| 333 |
|
|---|
| 334 | <p>will not compile with GNU libc (GNU/Linux libc6), because
|
|---|
| 335 | <code>stdin</code> is not a constant. This was done deliberately, to make
|
|---|
| 336 | it easier to maintain binary compatibility when the type <code>FILE</code>
|
|---|
| 337 | needs to be changed. It is surprising for people used to traditional Unix
|
|---|
| 338 | C libraries, but it is permitted by the C standard.</p>
|
|---|
| 339 |
|
|---|
| 340 | <p>This construct commonly occurs in code generated by old versions of
|
|---|
| 341 | lex or yacc. We suggest you try regenerating the parser with a
|
|---|
| 342 | current version of flex or bison, respectively. In your own code, the
|
|---|
| 343 | appropriate fix is to move the initialization to the beginning of
|
|---|
| 344 | main.</p>
|
|---|
| 345 |
|
|---|
| 346 | <p>There is a common misconception that the GCC developers are
|
|---|
| 347 | responsible for GNU libc. These are in fact two entirely separate
|
|---|
| 348 | projects; please check the
|
|---|
| 349 | <a href="http://www.gnu.org/software/glibc/">GNU libc web pages</a>
|
|---|
| 350 | for details.
|
|---|
| 351 | </p></dd>
|
|---|
| 352 |
|
|---|
| 353 | <dt>Cannot use preprocessor directive in macro arguments.</dt>
|
|---|
| 354 | <dd><p>Let me guess... you wrote code that looks something like this:</p>
|
|---|
| 355 | <blockquote><pre>
|
|---|
| 356 | memcpy(dest, src,
|
|---|
| 357 | #ifdef PLATFORM1
|
|---|
| 358 | 12
|
|---|
| 359 | #else
|
|---|
| 360 | 24
|
|---|
| 361 | #endif
|
|---|
| 362 | );
|
|---|
| 363 | </pre></blockquote>
|
|---|
| 364 | <p>and you got a whole pile of error messages:</p>
|
|---|
| 365 | <blockquote><code>
|
|---|
| 366 |
|
|---|
| 367 | test.c:11: warning: preprocessing directive not recognized within
|
|---|
| 368 | macro arg<br />
|
|---|
| 369 | test.c:11: warning: preprocessing directive not recognized within
|
|---|
| 370 | macro arg<br />
|
|---|
| 371 | test.c:11: warning: preprocessing directive not recognized within
|
|---|
| 372 | macro arg<br />
|
|---|
| 373 | test.c: In function `foo':<br />
|
|---|
| 374 | test.c:6: undefined or invalid # directive<br />
|
|---|
| 375 | test.c:8: undefined or invalid # directive<br />
|
|---|
| 376 | test.c:9: parse error before `24'<br />
|
|---|
| 377 | test.c:10: undefined or invalid # directive<br />
|
|---|
| 378 | test.c:11: parse error before `#'<br />
|
|---|
| 379 | </code></blockquote>
|
|---|
| 380 |
|
|---|
| 381 | <p><strong>Update:</strong> As of GCC 3.2 this kind of construct is
|
|---|
| 382 | always accepted and CPP will probably do what you expect, but see the
|
|---|
| 383 | manual for detailed semantics.</p>
|
|---|
| 384 |
|
|---|
| 385 | <p>However, versions of GCC prior to 3.2 did not allow you to put
|
|---|
| 386 | <code>#ifdef</code> (or any other directive) inside the arguments of a
|
|---|
| 387 | macro. Your C library's <code><string.h></code> happens to
|
|---|
| 388 | define <code>memcpy</code> as a macro - this is perfectly legitimate.
|
|---|
| 389 | The code therefore would not compile.</p>
|
|---|
| 390 |
|
|---|
| 391 | <p>This kind of code is not portable. It is "undefined behavior"
|
|---|
| 392 | according to the C standard; that means different compilers will do
|
|---|
| 393 | different things with it. It is always possible to rewrite code which
|
|---|
| 394 | uses conditionals inside macros so that it doesn't. You could write
|
|---|
| 395 | the above example</p>
|
|---|
| 396 | <blockquote><pre>
|
|---|
| 397 | #ifdef PLATFORM1
|
|---|
| 398 | memcpy(dest, src, 12);
|
|---|
| 399 | #else
|
|---|
| 400 | memcpy(dest, src, 24);
|
|---|
| 401 | #endif
|
|---|
| 402 | </pre></blockquote>
|
|---|
| 403 | <p>This is a bit more typing, but I personally think it's better style
|
|---|
| 404 | in addition to being more portable.</p>
|
|---|
| 405 |
|
|---|
| 406 | <p>In recent versions of glibc, <code>printf</code> is among the
|
|---|
| 407 | functions which are implemented as macros.</p></dd>
|
|---|
| 408 | </dl>
|
|---|
| 409 |
|
|---|
| 410 | <hr />
|
|---|
| 411 |
|
|---|
| 412 | <h2><a name="cplusplus">C++</a></h2>
|
|---|
| 413 |
|
|---|
| 414 | <p>This is the list of bugs (and non-bugs) in g++ (aka GNU C++) that
|
|---|
| 415 | are reported very often, but not yet fixed. While it is certainly
|
|---|
| 416 | better to fix bugs instead of documenting them, this document might
|
|---|
| 417 | save people the effort of writing a bug report when the bug is already
|
|---|
| 418 | well-known. <a href="#report">How to report bugs</a> tells you how to
|
|---|
| 419 | report a bug.</p>
|
|---|
| 420 |
|
|---|
| 421 | <p>There are many reasons why reported bugs don't get fixed. It might
|
|---|
| 422 | be difficult to fix, or fixing it might break compatibility. Often,
|
|---|
| 423 | reports get a low priority when there is a simple work-around. In
|
|---|
| 424 | particular, bugs caused by invalid C++ code have a simple work-around,
|
|---|
| 425 | <em>fix the code</em>. Now that there is an agreed ISO/ANSI standard
|
|---|
| 426 | for C++, the compiler has a definitive document to adhere to. Earlier
|
|---|
| 427 | versions might have accepted source code that is <em>no longer</em>
|
|---|
| 428 | C++. This means that code which might have `worked' in a previous
|
|---|
| 429 | version, is now rejected. You should update your code to be C++.</p>
|
|---|
| 430 |
|
|---|
| 431 | <p>You should try to use the latest stable release of the GNU C++
|
|---|
| 432 | compiler.</p>
|
|---|
| 433 |
|
|---|
| 434 | <h3><a name="updating">Common problems updating from G++ 2.95 to G++
|
|---|
| 435 | 3.0</a></h3>
|
|---|
| 436 |
|
|---|
| 437 | <p>G++ 3.0 conforms much closer to the ISO C++ standard (available at
|
|---|
| 438 | <a href="http://www.ncits.org/cplusplus.htm">http://www.ncits.org/cplusplus.htm</a>).</p>
|
|---|
| 439 |
|
|---|
| 440 | <p>We have also implemented some of the core and library defect reports
|
|---|
| 441 | (available at
|
|---|
| 442 | <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html">http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a>
|
|---|
| 443 | &
|
|---|
| 444 | <a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html">
|
|---|
| 445 | http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a>
|
|---|
| 446 | respectively).</p>
|
|---|
| 447 |
|
|---|
| 448 | <ul>
|
|---|
| 449 |
|
|---|
| 450 | <li>The ABI has changed. This means that both class layout and name
|
|---|
| 451 | mangling is different. You <em>must</em> recompile all c++ libraries (if
|
|---|
| 452 | you don't you will get link errors).</li>
|
|---|
| 453 |
|
|---|
| 454 | <li>The standard library is much more conformant, and uses the
|
|---|
| 455 | <code>std::</code> namespace.</li>
|
|---|
| 456 |
|
|---|
| 457 | <li><code>std::</code> is now a real namespace, not an alias for
|
|---|
| 458 | <code>::</code>.</li>
|
|---|
| 459 |
|
|---|
| 460 | <li>The standard header files for the c library don't end with
|
|---|
| 461 | <code>.h</code>, but begin with <code>c</code> (i.e.
|
|---|
| 462 | <code><cstdlib></code> rather than <code><stdlib.h></code>).
|
|---|
| 463 | The <code>.h</code> names are still available, but are deprecated.</li>
|
|---|
| 464 |
|
|---|
| 465 | <li><code><strstream></code> is deprecated, use
|
|---|
| 466 | <code><sstream></code> instead.</li>
|
|---|
| 467 |
|
|---|
| 468 | <li><code>streambuf::seekoff</code> &
|
|---|
| 469 | <code>streambuf::seekpos</code> are private, instead use
|
|---|
| 470 | <code>streambuf::pubseekoff</code> &
|
|---|
| 471 | <code>streambuf::pubseekpos</code> respectively.</li>
|
|---|
| 472 |
|
|---|
| 473 | <li>If <code>std::operator << (std::ostream &, long long)</code>
|
|---|
| 474 | doesn't exist, you need to recompile libstdc++ with
|
|---|
| 475 | <code>--enable-long-long</code>.</li>
|
|---|
| 476 |
|
|---|
| 477 | </ul>
|
|---|
| 478 |
|
|---|
| 479 | This means you may get lots of errors about things like
|
|---|
| 480 | <code>strcmp</code> not being found. You've most likely forgotten to
|
|---|
| 481 | tell the compiler to look in the <code>std::</code> namespace. There are
|
|---|
| 482 | several ways to do this,
|
|---|
| 483 |
|
|---|
| 484 | <ul>
|
|---|
| 485 |
|
|---|
| 486 | <li>Say, <code>std::strcmp</code> at the call. This is the most explicit
|
|---|
| 487 | way of saying what you mean.</li>
|
|---|
| 488 |
|
|---|
| 489 | <li>Say, <code>using std::strcmp;</code> somewhere before the call. You
|
|---|
| 490 | will need to do this for each function or type you wish to use from the
|
|---|
| 491 | standard library.</li>
|
|---|
| 492 |
|
|---|
| 493 | <li>Say, <code>using namespace std;</code> somewhere before the call.
|
|---|
| 494 | This is the quick-but-dirty fix. This brings the <em>whole</em> of the
|
|---|
| 495 | <code>std::</code> namespace into scope. <em>Never</em> do this in a
|
|---|
| 496 | header file, as you will be forcing users of your header file to do the
|
|---|
| 497 | same.</li>
|
|---|
| 498 |
|
|---|
| 499 | </ul>
|
|---|
| 500 |
|
|---|
| 501 | <h3><a name="abi">ABI bugs</a></h3>
|
|---|
| 502 |
|
|---|
| 503 | <p>3.0 had a new ABI, which affected class layout, function mangling and
|
|---|
| 504 | calling conventions. We had intended it to be complete, unfortunately
|
|---|
| 505 | some issues came to light, too late to fix in the 3.0 series.
|
|---|
| 506 | The ABI should not change in dot releases, so we addressed most issues
|
|---|
| 507 | in GCC 3.1.
|
|---|
| 508 | </p>
|
|---|
| 509 |
|
|---|
| 510 | <dl>
|
|---|
| 511 |
|
|---|
| 512 | <dt>Covariant return types</dt>
|
|---|
| 513 |
|
|---|
| 514 | <dd>We do not implement non-trivial covariant returns. We also generate
|
|---|
| 515 | incorrect virtual function tables for trivial covariance. Although
|
|---|
| 516 | trivial covariance will work, it is incompatible with the ABI. GNATS PR
|
|---|
| 517 | 3706 tracks this problem.</dd>
|
|---|
| 518 |
|
|---|
| 519 | </dl>
|
|---|
| 520 |
|
|---|
| 521 | <h3><a name="nonbugs">Non-bugs</a></h3>
|
|---|
| 522 |
|
|---|
| 523 | <p>Here are some features that have been reported as bugs, but are
|
|---|
| 524 | not.</p>
|
|---|
| 525 |
|
|---|
| 526 | <dl>
|
|---|
| 527 |
|
|---|
| 528 | <dt>Nested classes can access private types of the containing
|
|---|
| 529 | class.</dt>
|
|---|
| 530 | <dd><p>G++ now implements type access control on member types. Defect
|
|---|
| 531 | report 45 clarifies that nested classes are members of the class they
|
|---|
| 532 | are nested in, and so are granted access to private members of that
|
|---|
| 533 | class.</p></dd>
|
|---|
| 534 |
|
|---|
| 535 | <dt>Classes in exception specifiers must be complete types.</dt>
|
|---|
| 536 | <dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or
|
|---|
| 537 | pointer to incomplete (other than <code><i>cv</i> void *</code>) in
|
|---|
| 538 | an exception specification.</p></dd>
|
|---|
| 539 |
|
|---|
| 540 | <dt>G++ emits two copies of constructors and destructors.</dt>
|
|---|
| 541 |
|
|---|
| 542 | <dd><p>In general there are <em>three</em> types of constructors (and
|
|---|
| 543 | destructors).</p>
|
|---|
| 544 | <ol>
|
|---|
| 545 | <li>The complete object constructor/destructor.</li>
|
|---|
| 546 | <li>The base object constructor/destructor.</li>
|
|---|
| 547 | <li>The allocating destructor/deallocating destructor.</li>
|
|---|
| 548 | </ol>
|
|---|
| 549 | <p>The first two are different, when virtual base classes are involved.
|
|---|
| 550 | In some cases we can do better, and this is logged in GNATS.</p></dd>
|
|---|
| 551 |
|
|---|
| 552 | <dt>Exceptions don't work in multithreaded applications.</dt>
|
|---|
| 553 |
|
|---|
| 554 | <dd><p>You need to rebuild g++ and libstdc++ with
|
|---|
| 555 | <code>--enable-threads</code>. Remember, c++ exceptions are not like
|
|---|
| 556 | hardware interrupts. You cannot throw an exception in one thread and
|
|---|
| 557 | catch it in another. You cannot throw an exception from a signal
|
|---|
| 558 | handler, and catch it in the main thread.</p></dd>
|
|---|
| 559 |
|
|---|
| 560 | <dt>Global destructors are not run in the correct order.</dt>
|
|---|
| 561 |
|
|---|
| 562 | <dd><p>Global destructors should be run in the reverse order of their
|
|---|
| 563 | constructors <em>completing</em>. In most cases this is the same as
|
|---|
| 564 | the reverse order of constructors <em>starting</em>, but sometimes it
|
|---|
| 565 | is different, and that is important. You need to compile and link your
|
|---|
| 566 | programs with <code>--use-cxa-atexit</code>. We have not turned this
|
|---|
| 567 | switch on by default, as it requires a <code>cxa</code> aware runtime
|
|---|
| 568 | library (<code>libc</code>, <code>glibc</code>, or
|
|---|
| 569 | equivalent).</p></dd>
|
|---|
| 570 |
|
|---|
| 571 | <dt>Problems with floating point computations.</dt>
|
|---|
| 572 | <dd><p>In a number of cases, GCC appears to perform floating point
|
|---|
| 573 | computations incorrectly. For example, the program</p>
|
|---|
| 574 | <blockquote><code>
|
|---|
| 575 | #include <iostream><br />
|
|---|
| 576 | <br />
|
|---|
| 577 | int main() {<br />
|
|---|
| 578 | <br />
|
|---|
| 579 | double min = 0.0;<br />
|
|---|
| 580 | double max = 0.5;<br />
|
|---|
| 581 | double width = 0.01;<br />
|
|---|
| 582 | std::cout << (int)(((max - min) / width) - 1) <<
|
|---|
| 583 | std::endl;<br />
|
|---|
| 584 | <br />
|
|---|
| 585 | }<br />
|
|---|
| 586 | </code></blockquote>
|
|---|
| 587 | <p>might print 49 on some systems and optimization levels, and 48 on
|
|---|
| 588 | others.</p>
|
|---|
| 589 |
|
|---|
| 590 | <p>The is the result of <em>rounding</em>: The computer cannot
|
|---|
| 591 | represent all real numbers exactly, so it has to use
|
|---|
| 592 | approximations. When computing with approximation, the computer needs
|
|---|
| 593 | to round to the nearest representable number.</p>
|
|---|
| 594 |
|
|---|
| 595 | <p>This is not a bug in the compiler, but an inherent limitation of
|
|---|
| 596 | the float and double types. Please study
|
|---|
| 597 | <a href="http://www.validlab.com/goldberg/paper.ps">this paper</a>
|
|---|
| 598 | for more information.</p></dd>
|
|---|
| 599 |
|
|---|
| 600 | <dt>Templates, scoping, and digraphs.</dt>
|
|---|
| 601 |
|
|---|
| 602 | <dd><p>If you have a class in global namespace, say named
|
|---|
| 603 | <code>X</code>, and want to give it as a template argument to some
|
|---|
| 604 | other class, say <code>std::vector</code>, then this here fails with a
|
|---|
| 605 | parser error: <code>std::vector<::X></code>.
|
|---|
| 606 | </p>
|
|---|
| 607 |
|
|---|
| 608 | <p>
|
|---|
| 609 | The reason is that the standard mandates that the sequence
|
|---|
| 610 | <code><:</code> is treated as if it were the token
|
|---|
| 611 | <code>[</code>, and the parser then reports a parse error before the
|
|---|
| 612 | character <code>:</code> (by which it means the second
|
|---|
| 613 | colon). There are several such combinations of characters, and
|
|---|
| 614 | they are called <em>digraphs</em>.
|
|---|
| 615 | </p>
|
|---|
| 616 |
|
|---|
| 617 | <p>
|
|---|
| 618 | The simplest way to avoid this is to write <code>std::vector<
|
|---|
| 619 | ::X></code>, i.e. place a space between the opening angle bracket
|
|---|
| 620 | and the scope operator.
|
|---|
| 621 | </p></dd>
|
|---|
| 622 |
|
|---|
| 623 |
|
|---|
| 624 | </dl>
|
|---|
| 625 |
|
|---|
| 626 | <h3><a name="missing">Missing features</a></h3>
|
|---|
| 627 | <p>We know some things are missing from G++.</p>
|
|---|
| 628 |
|
|---|
| 629 | <dl>
|
|---|
| 630 |
|
|---|
| 631 | <dt>The <code>export</code> keyword is not implemented.</dt>
|
|---|
| 632 | <dd><p>Most C++ compilers (G++ included) do not yet implement
|
|---|
| 633 | <code>export</code>, which is necessary for separate compilation of
|
|---|
| 634 | template declarations and definitions. Without <code>export</code>, a
|
|---|
| 635 | template definition must be in scope to be used. The obvious
|
|---|
| 636 | workaround is simply to place all definitions in the header
|
|---|
| 637 | itself. Alternatively, the compilation unit containing template
|
|---|
| 638 | definitions may be included from the header.</p></dd>
|
|---|
| 639 |
|
|---|
| 640 | <dt>Two stage lookup in templates is not implemented.</dt>
|
|---|
| 641 | <dd><p>[14.6] specifies how names are looked up inside a template. G++
|
|---|
| 642 | does not do this correctly, but for most templates this will not be
|
|---|
| 643 | noticeable.</p></dd>
|
|---|
| 644 |
|
|---|
| 645 | </dl>
|
|---|
| 646 |
|
|---|
| 647 | <h3><a name="parsing">Parse errors for "simple" code</a></h3>
|
|---|
| 648 |
|
|---|
| 649 | Up to and including GCC 3.0, the compiler will give "parse error" for
|
|---|
| 650 | seemingly simple code, such as
|
|---|
| 651 |
|
|---|
| 652 | <pre>
|
|---|
| 653 | struct A{
|
|---|
| 654 | A();
|
|---|
| 655 | A(int);
|
|---|
| 656 | void func();
|
|---|
| 657 | };
|
|---|
| 658 |
|
|---|
| 659 | struct B{
|
|---|
| 660 | B(A);
|
|---|
| 661 | B(A,A);
|
|---|
| 662 | void func();
|
|---|
| 663 | };
|
|---|
| 664 |
|
|---|
| 665 | void foo(){
|
|---|
| 666 | B b(A(),A(1)); //Variable b, initialized with two temporaries
|
|---|
| 667 | B(A(2)).func(); //B temporary, initialized with A temporary
|
|---|
| 668 | }
|
|---|
| 669 | </pre>
|
|---|
| 670 | The problem is that GCC starts to parse the declaration of
|
|---|
| 671 | <code>b</code> as a function <code>b</code> returning <code>B</code>,
|
|---|
| 672 | taking a function returning <code>A</code> as an argument. When it
|
|---|
| 673 | sees the 1, it is too late. The work-around in these cases is to add
|
|---|
| 674 | additional parentheses around the expressions that are mistaken as
|
|---|
| 675 | declarations:
|
|---|
| 676 | <pre>
|
|---|
| 677 | (B(A(2))).func();
|
|---|
| 678 | </pre>
|
|---|
| 679 | Sometimes, even that is not enough; to show the compiler that this
|
|---|
| 680 | should be really an expression, a comma operator with a dummy argument
|
|---|
| 681 | can be used:
|
|---|
| 682 | <pre>
|
|---|
| 683 | B b((0,A()),A(1));
|
|---|
| 684 | </pre>
|
|---|
| 685 | <p>
|
|---|
| 686 | Another example is the parse error for the <code>return</code>
|
|---|
| 687 | statement in</p>
|
|---|
| 688 | <pre>
|
|---|
| 689 | struct A{};
|
|---|
| 690 |
|
|---|
| 691 | struct B{
|
|---|
| 692 | A a;
|
|---|
| 693 | A f1(bool);
|
|---|
| 694 | };
|
|---|
| 695 |
|
|---|
| 696 | A B::f1(bool b)
|
|---|
| 697 | {
|
|---|
| 698 | if (b)
|
|---|
| 699 | return (A());
|
|---|
| 700 | return a;
|
|---|
| 701 | }
|
|---|
| 702 | </pre>
|
|---|
| 703 | <p>The problem is that the compiler interprets <code>A()</code> as a
|
|---|
| 704 | function (taking no arguments, returning <code>A</code>), and
|
|---|
| 705 | <code>(A()</code>) as a cast - with a missing expression, hence the
|
|---|
| 706 | parse error. The work-around is to omit the parentheses:</p>
|
|---|
| 707 | <pre>
|
|---|
| 708 | if (b)
|
|---|
| 709 | return A();
|
|---|
| 710 | </pre>
|
|---|
| 711 | <p>This problem occurs in a number of variants; in <code>throw</code>
|
|---|
| 712 | statements, people also frequently put the object in parentheses. The
|
|---|
| 713 | exact error also somewhat varies with the compiler version. The
|
|---|
| 714 | work-arounds proposed do not change the semantics of the program at
|
|---|
| 715 | all; they make them perhaps less readable.</p>
|
|---|
| 716 |
|
|---|
| 717 | <h3><a name="-O3">Optimization at <code>-O3</code> takes a
|
|---|
| 718 | very long time</a></h3>
|
|---|
| 719 | <p>At <code>-O3</code>, all functions are candidates for inlining. The
|
|---|
| 720 | heuristic used has some deficiencies which show up when allowed such
|
|---|
| 721 | freedom. This is g++ specific, as it has an earlier inliner than
|
|---|
| 722 | gcc.</p>
|
|---|
| 723 |
|
|---|
| 724 | </body>
|
|---|
| 725 | </html>
|
|---|
