| 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://gcc.gnu.org/bugs.html">http://gcc.gnu.org/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="#known">Frequently Reported Bugs in GCC</a>
|
|---|
| 28 | <ul>
|
|---|
| 29 | <li><a href="#cxx">C++</a>
|
|---|
| 30 | <ul>
|
|---|
| 31 | <li><a href="#missing">Missing features</a></li>
|
|---|
| 32 | <li><a href="#fixed34">Bugs fixed in the 3.4 series</a></li>
|
|---|
| 33 | </ul>
|
|---|
| 34 | </li>
|
|---|
| 35 | <li><a href="#fortran">Fortran</a></li>
|
|---|
| 36 | </ul>
|
|---|
| 37 | </li>
|
|---|
| 38 | <li><a href="#nonbugs">Non-bugs</a>
|
|---|
| 39 | <ul>
|
|---|
| 40 | <li><a href="#nonbugs_general">General</a></li>
|
|---|
| 41 | <li><a href="#nonbugs_c">C</a></li>
|
|---|
| 42 | <li><a href="#nonbugs_cxx">C++</a>
|
|---|
| 43 | <ul>
|
|---|
| 44 | <li><a href="#upgrading">Common problems when upgrading the compiler</a></li>
|
|---|
| 45 | </ul>
|
|---|
| 46 | </li>
|
|---|
| 47 | </ul>
|
|---|
| 48 | </li>
|
|---|
| 49 | </ul>
|
|---|
| 50 |
|
|---|
| 51 | <hr />
|
|---|
| 52 |
|
|---|
| 53 | <h1><a name="report">Reporting Bugs</a></h1>
|
|---|
| 54 |
|
|---|
| 55 | <p>The main purpose of a bug report is to enable us to fix the bug. The
|
|---|
| 56 | most important prerequisite for this is that the report must be complete and
|
|---|
| 57 | self-contained, which we explain in detail below.</p>
|
|---|
| 58 |
|
|---|
| 59 | <p>Before you report a bug, please check the
|
|---|
| 60 | <a href="#known">list of well-known bugs</a> and, <strong>if possible
|
|---|
| 61 | in any way, try a current development snapshot</strong>.
|
|---|
| 62 | If you want to report a bug with versions of GCC before 3.1 we strongly
|
|---|
| 63 | recommend upgrading to the current release first.</p>
|
|---|
| 64 |
|
|---|
| 65 | <p>Before reporting that GCC compiles your code incorrectly, please
|
|---|
| 66 | compile it with <code>gcc -Wall</code> and see whether this shows
|
|---|
| 67 | anything wrong with your code that could be the cause instead of a bug
|
|---|
| 68 | in GCC.</p>
|
|---|
| 69 |
|
|---|
| 70 | <h2>Summarized bug reporting instructions</h2>
|
|---|
| 71 |
|
|---|
| 72 | <p>After this summary, you'll find detailed bug reporting
|
|---|
| 73 | instructions, that explain how to obtain some of the information
|
|---|
| 74 | requested in this summary.</p>
|
|---|
| 75 |
|
|---|
| 76 | <h3><a name="need">What we need</a></h3>
|
|---|
| 77 |
|
|---|
| 78 | <p>Please include in your bug report all of the following items, the first
|
|---|
| 79 | three of which can be obtained from the output of <code>gcc -v</code>:</p>
|
|---|
| 80 |
|
|---|
| 81 | <ul>
|
|---|
| 82 | <li>the exact version of GCC;</li>
|
|---|
| 83 | <li>the system type;</li>
|
|---|
| 84 | <li>the options given when GCC was configured/built;</li>
|
|---|
| 85 | <li>the complete command line that triggers the bug;</li>
|
|---|
| 86 | <li>the compiler output (error messages, warnings, etc.); and</li>
|
|---|
| 87 | <li>the <em>preprocessed</em> file (<code>*.i*</code>) that triggers the
|
|---|
| 88 | bug, generated by adding <code>-save-temps</code> to the complete
|
|---|
| 89 | compilation command, or, in the case of a bug report for the GNAT front end,
|
|---|
| 90 | a complete set of source files (see below).</li>
|
|---|
| 91 | </ul>
|
|---|
| 92 |
|
|---|
| 93 | <h3><a name="dontwant">What we do <strong>not</strong> want</a></h3>
|
|---|
| 94 |
|
|---|
| 95 | <ul>
|
|---|
| 96 | <li>A source file that <code>#include</code>s header files that are left
|
|---|
| 97 | out of the bug report (see above)</li>
|
|---|
| 98 |
|
|---|
| 99 | <li>That source file and a collection of header files.</li>
|
|---|
| 100 |
|
|---|
| 101 | <li>An attached archive (tar, zip, shar, whatever) containing all
|
|---|
| 102 | (or some :-) of the above.</li>
|
|---|
| 103 |
|
|---|
| 104 | <li>A code snippet that won't cause the compiler to produce the
|
|---|
| 105 | exact output mentioned in the bug report (e.g., a snippet with just
|
|---|
| 106 | a few lines around the one that <b>apparently</b> triggers the bug,
|
|---|
| 107 | with some pieces replaced with ellipses or comments for extra
|
|---|
| 108 | obfuscation :-)</li>
|
|---|
| 109 |
|
|---|
| 110 | <li>The location (URL) of the package that failed to build (we won't
|
|---|
| 111 | download it, anyway, since you've already given us what we need to
|
|---|
| 112 | duplicate the bug, haven't you? :-)</li>
|
|---|
| 113 |
|
|---|
| 114 | <li>An error that occurs only some of the times a certain file is
|
|---|
| 115 | compiled, such that retrying a sufficient number of times results in
|
|---|
| 116 | a successful compilation; this is a symptom of a hardware problem,
|
|---|
| 117 | not of a compiler bug (sorry)</li>
|
|---|
| 118 |
|
|---|
| 119 | <li>E-mail messages that complement previous, incomplete bug
|
|---|
| 120 | reports. Post a new, self-contained, full bug report instead, if
|
|---|
| 121 | possible as a follow-up to the original bug report</li>
|
|---|
| 122 |
|
|---|
| 123 | <li>Assembly files (<code>*.s</code>) produced by the compiler, or any
|
|---|
| 124 | binary files, such as object files, executables, core files, or
|
|---|
| 125 | precompiled header files</li>
|
|---|
| 126 |
|
|---|
| 127 | <li>Duplicate bug reports, or reports of bugs already fixed in the
|
|---|
| 128 | development tree, especially those that have already been reported
|
|---|
| 129 | as fixed last week :-)</li>
|
|---|
| 130 |
|
|---|
| 131 | <li>Bugs in the assembler, the linker or the C library. These are
|
|---|
| 132 | separate projects, with separate mailing lists and different bug
|
|---|
| 133 | reporting procedures</li>
|
|---|
| 134 |
|
|---|
| 135 | <li>Bugs in releases or snapshots of GCC not issued by the GNU
|
|---|
| 136 | Project. Report them to whoever provided you with the release</li>
|
|---|
| 137 |
|
|---|
| 138 | <li>Questions about the correctness or the expected behavior of
|
|---|
| 139 | certain constructs that are not GCC extensions. Ask them in forums
|
|---|
| 140 | dedicated to the discussion of the programming language</li>
|
|---|
| 141 | </ul>
|
|---|
| 142 |
|
|---|
| 143 | <h3><a name="where">Where to post it</a></h3>
|
|---|
| 144 |
|
|---|
| 145 | <p>Please submit your bug report directly to the
|
|---|
| 146 | <a href="http://gcc.gnu.org/bugzilla/">GCC bug database</a>.
|
|---|
| 147 | Alternatively, you can use the <code>gccbug</code> script that mails your bug
|
|---|
| 148 | report to the bug database.
|
|---|
| 149 | <br />
|
|---|
| 150 | Only if all this is absolutely impossible, mail all information to
|
|---|
| 151 | <a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a>.</p>
|
|---|
| 152 |
|
|---|
| 153 | <h2><a name="detailed">Detailed bug reporting instructions</a></h2>
|
|---|
| 154 |
|
|---|
| 155 | <p>Please refer to the <a href="#gnat">next section</a> when reporting
|
|---|
| 156 | bugs in GNAT, the Ada compiler, or to the <a href="#pch">one after
|
|---|
| 157 | that</a> when reporting bugs that appear when using a precompiled header.</p>
|
|---|
| 158 |
|
|---|
| 159 | <p>In general, all the information we need can be obtained by
|
|---|
| 160 | collecting the command line below, as well as its output and the
|
|---|
| 161 | preprocessed file it generates.</p>
|
|---|
| 162 |
|
|---|
| 163 | <blockquote><p><code>gcc -v -save-temps <i>all-your-options
|
|---|
| 164 | source-file</i></code></p></blockquote>
|
|---|
| 165 |
|
|---|
| 166 | <p>Typically the preprocessed file (extension <code>.i</code> for C or
|
|---|
| 167 | <code>.ii</code> for C++, and <code>.f</code> if the preprocessor is used on
|
|---|
| 168 | Fortran files) will be large, so please compress the
|
|---|
| 169 | resulting file with one of the popular compression programs such as
|
|---|
| 170 | bzip2, gzip, zip or compress (in
|
|---|
| 171 | decreasing order of preference). Use maximum compression
|
|---|
| 172 | (<code>-9</code>) if available. Please include the compressed
|
|---|
| 173 | preprocessor output in your bug report, even if the source code is
|
|---|
| 174 | freely available elsewhere; it makes the job of our volunteer testers
|
|---|
| 175 | much easier.</p>
|
|---|
| 176 |
|
|---|
| 177 | <p>The <b>only</b> excuses to not send us the preprocessed sources are
|
|---|
| 178 | (i) if you've found a bug in the preprocessor, (ii) if you've reduced
|
|---|
| 179 | the testcase to a small file that doesn't include any other file or
|
|---|
| 180 | (iii) if the bug appears only when using precompiled headers. If you
|
|---|
| 181 | can't post the preprocessed sources because they're proprietary code,
|
|---|
| 182 | then try to create a small file that triggers the same problem.</p>
|
|---|
| 183 |
|
|---|
| 184 | <p>Since we're supposed to be able to re-create the assembly output
|
|---|
| 185 | (extension <code>.s</code>), you usually should not include
|
|---|
| 186 | it in the bug report, although you may want to post parts of it to
|
|---|
| 187 | point out assembly code you consider to be wrong.</p>
|
|---|
| 188 |
|
|---|
| 189 | <p>Whether to use MIME attachments or <code>uuencode</code> is up to
|
|---|
| 190 | you. In any case, make sure the compiler command line, version and
|
|---|
| 191 | error output are in plain text, so that we don't have to decode the
|
|---|
| 192 | bug report in order to tell who should take care of it. A meaningful
|
|---|
| 193 | subject indicating language and platform also helps.</p>
|
|---|
| 194 |
|
|---|
| 195 | <p>Please avoid posting an archive (.tar, .shar or .zip); we generally
|
|---|
| 196 | need just a single file to reproduce the bug (the .i/.ii/.f preprocessed
|
|---|
| 197 | file), and, by storing it in an archive, you're just making our
|
|---|
| 198 | volunteers' jobs harder. Only when your bug report requires multiple
|
|---|
| 199 | source files to be reproduced should you use an archive. This is, for example,
|
|---|
| 200 | the case if you are using <code>INCLUDE</code> directives in Fortran code,
|
|---|
| 201 | which are not processed by the preprocessor, but the compiler. In that case,
|
|---|
| 202 | we need the main file and all <code>INCLUDE</code>d files. In any case,
|
|---|
| 203 | make sure the compiler version, error message, etc, are included in
|
|---|
| 204 | the body of your bug report as plain text, even if needlessly
|
|---|
| 205 | duplicated as part of an archive.</p>
|
|---|
| 206 |
|
|---|
| 207 | <p>If you fail to supply enough information for a bug report to be
|
|---|
| 208 | reproduced, someone will probably ask you to post additional
|
|---|
| 209 | information (or just ignore your bug report, if they're in a bad day,
|
|---|
| 210 | so try to get it right on the first posting :-). In this case, please
|
|---|
| 211 | post the additional information to the bug reporting mailing list, not
|
|---|
| 212 | just to the person who requested it, unless explicitly told so. If
|
|---|
| 213 | possible, please include in this follow-up all the information you had
|
|---|
| 214 | supplied in the incomplete bug report (including the preprocessor
|
|---|
| 215 | output), so that the new bug report is self-contained.</p>
|
|---|
| 216 |
|
|---|
| 217 | <h2><a name="gnat">Detailed bug reporting instructions for GNAT</a></h2>
|
|---|
| 218 |
|
|---|
| 219 | <p>See the <a href="#detailed">previous section</a> for bug reporting
|
|---|
| 220 | instructions for GCC language implementations other than Ada.</p>
|
|---|
| 221 |
|
|---|
| 222 | <p>Bug reports have to contain at least the following information in
|
|---|
| 223 | order to be useful:</p>
|
|---|
| 224 |
|
|---|
| 225 | <ul>
|
|---|
| 226 | <li>the exact version of GCC, as shown by "<code>gcc -v</code>";</li>
|
|---|
| 227 | <li>the system type;</li>
|
|---|
| 228 | <li>the options when GCC was configured/built;</li>
|
|---|
| 229 | <li>the exact command line passed to the <code>gcc</code> program
|
|---|
| 230 | triggering the bug
|
|---|
| 231 | (not just the flags passed to <code>gnatmake</code>, but
|
|---|
| 232 | <code>gnatmake</code> prints the parameters it passed to <code>gcc</code>)</li>
|
|---|
| 233 | <li>a collection of source files for reproducing the bug,
|
|---|
| 234 | preferably a minimal set (see below);</li>
|
|---|
| 235 | <li>a description of the expected behavior;</li>
|
|---|
| 236 | <li>a description of actual behavior.</li>
|
|---|
| 237 | </ul>
|
|---|
| 238 |
|
|---|
| 239 | <p>If your code depends on additional source files (usually package
|
|---|
| 240 | specifications), submit the source code for these compilation units in
|
|---|
| 241 | a single file that is acceptable input to <code>gnatchop</code>,
|
|---|
| 242 | i.e. contains no non-Ada text. If the compilation terminated
|
|---|
| 243 | normally, you can usually obtain a list of dependencies using the
|
|---|
| 244 | "<code>gnatls -d <i>main_unit</i></code>" command, where
|
|---|
| 245 | <code><i>main_unit</i></code> is the file name of the main compilation
|
|---|
| 246 | unit (which is also passed to <code>gcc</code>).</p>
|
|---|
| 247 |
|
|---|
| 248 | <p>If you report a bug which causes the compiler to print a bug box,
|
|---|
| 249 | include that bug box in your report, and do not forget to send all the
|
|---|
| 250 | source files listed after the bug box along with your report.</p>
|
|---|
| 251 |
|
|---|
| 252 | <p>If you use <code>gnatprep</code>, be sure to send in preprocessed
|
|---|
| 253 | sources (unless you have to report a bug in <code>gnatprep</code>).</p>
|
|---|
| 254 |
|
|---|
| 255 | <p>When you have checked that your report meets these criteria, please
|
|---|
| 256 | submit it according to our <a href="#where">generic instructions</a>.
|
|---|
| 257 | (If you use a mailing list for reporting, please include an
|
|---|
| 258 | "<code>[Ada]</code>" tag in the subject.)</p>
|
|---|
| 259 |
|
|---|
| 260 | <h2><a name="pch">Detailed bug reporting instructions when using a
|
|---|
| 261 | precompiled header</a></h2>
|
|---|
| 262 |
|
|---|
| 263 | <p>If you're encountering a bug when using a precompiled header, the
|
|---|
| 264 | first thing to do is to delete the precompiled header, and try running
|
|---|
| 265 | the same GCC command again. If the bug happens again, the bug doesn't
|
|---|
| 266 | really involve precompiled headers, please report it without using
|
|---|
| 267 | them by following the instructions <a href="#detailed">above</a>.</p>
|
|---|
| 268 |
|
|---|
| 269 | <p>If you've found a bug while <i>building</i> a precompiled header
|
|---|
| 270 | (for instance, the compiler crashes), follow the usual instructions
|
|---|
| 271 | <a href="#detailed">above</a>.</p>
|
|---|
| 272 |
|
|---|
| 273 | <p>If you've found a real precompiled header bug, what we'll need to
|
|---|
| 274 | reproduce it is the sources to build the precompiled header (as a
|
|---|
| 275 | single <code>.i</code> file), the source file that uses the
|
|---|
| 276 | precompiled header, any other headers that source file includes, and
|
|---|
| 277 | the command lines that you used to build the precompiled header and to
|
|---|
| 278 | use it.</p>
|
|---|
| 279 |
|
|---|
| 280 | <p>Please <strong>don't</strong> send us the actual precompiled
|
|---|
| 281 | header. It is likely to be very large and we can't use it to
|
|---|
| 282 | reproduce the problem.</p>
|
|---|
| 283 |
|
|---|
| 284 | <hr />
|
|---|
| 285 |
|
|---|
| 286 | <h1><a name="known">Frequently Reported Bugs in GCC</a></h1>
|
|---|
| 287 |
|
|---|
| 288 | <p>This is a list of bugs in GCC that are reported very often, but not
|
|---|
| 289 | yet fixed. While it is certainly better to fix bugs instead of documenting
|
|---|
| 290 | them, this document might save people the effort of writing a bug report
|
|---|
| 291 | when the bug is already well-known.</p>
|
|---|
| 292 |
|
|---|
| 293 | <p>There are many reasons why a reported bug doesn't get fixed.
|
|---|
| 294 | It might be difficult to fix, or fixing it might break compatibility.
|
|---|
| 295 | Often, reports get a low priority when there is a simple work-around.
|
|---|
| 296 | In particular, bugs caused by invalid code have a simple work-around:
|
|---|
| 297 | <em>fix the code</em>.</p>
|
|---|
| 298 |
|
|---|
| 299 | <hr />
|
|---|
| 300 |
|
|---|
| 301 | <h2><a name="cxx">C++</a></h2>
|
|---|
| 302 |
|
|---|
| 303 | <h3><a name="missing">Missing features</a></h3>
|
|---|
| 304 |
|
|---|
| 305 | <dl>
|
|---|
| 306 |
|
|---|
| 307 | <dt>The <code>export</code> keyword is not implemented.</dt>
|
|---|
| 308 | <dd><p>Most C++ compilers (G++ included) do not yet implement
|
|---|
| 309 | <code>export</code>, which is necessary for separate compilation of
|
|---|
| 310 | template declarations and definitions. Without <code>export</code>, a
|
|---|
| 311 | template definition must be in scope to be used. The obvious
|
|---|
| 312 | workaround is simply to place all definitions in the header
|
|---|
| 313 | itself. Alternatively, the compilation unit containing template
|
|---|
| 314 | definitions may be included from the header.</p></dd>
|
|---|
| 315 |
|
|---|
| 316 | </dl>
|
|---|
| 317 |
|
|---|
| 318 | <h3><a name="fixed34">Bugs fixed in the 3.4 series</a></h3>
|
|---|
| 319 |
|
|---|
| 320 | <p>The following bugs are present up to (and including) GCC 3.3.x.
|
|---|
| 321 | They have been fixed in 3.4.0.</p>
|
|---|
| 322 |
|
|---|
| 323 | <dl>
|
|---|
| 324 |
|
|---|
| 325 | <dt>Two-stage name-lookup.</dt>
|
|---|
| 326 |
|
|---|
| 327 | <dd><p>GCC did not implement two-stage name-lookup (also see
|
|---|
| 328 | <a href="#new34">below</a>).</p></dd>
|
|---|
| 329 |
|
|---|
| 330 | <dt>Covariant return types.</dt>
|
|---|
| 331 |
|
|---|
| 332 | <dd><p>GCC did not implement non-trivial covariant returns.</p></dd>
|
|---|
| 333 |
|
|---|
| 334 | <dt>Parse errors for "simple" code.</dt>
|
|---|
| 335 |
|
|---|
| 336 | <dd><p>GCC gave parse errors for seemingly simple code, such as</p>
|
|---|
| 337 |
|
|---|
| 338 | <blockquote><pre>
|
|---|
| 339 | struct A
|
|---|
| 340 | {
|
|---|
| 341 | A();
|
|---|
| 342 | A(int);
|
|---|
| 343 | };
|
|---|
| 344 |
|
|---|
| 345 | struct B
|
|---|
| 346 | {
|
|---|
| 347 | B(A);
|
|---|
| 348 | B(A,A);
|
|---|
| 349 | void foo();
|
|---|
| 350 | };
|
|---|
| 351 |
|
|---|
| 352 | A bar()
|
|---|
| 353 | {
|
|---|
| 354 | B b(A(),A(1)); // Variable b, initialized with two temporaries
|
|---|
| 355 | B(A(2)).foo(); // B temporary, initialized with A temporary
|
|---|
| 356 | return (A()); // return A temporary
|
|---|
| 357 | }
|
|---|
| 358 | </pre></blockquote>
|
|---|
| 359 |
|
|---|
| 360 | <p>Although being valid code, each of the three lines with a comment was
|
|---|
| 361 | rejected by GCC. The work-arounds for older compiler versions proposed
|
|---|
| 362 | below do not change the semantics of the programs at all.</p>
|
|---|
| 363 |
|
|---|
| 364 | <p>The problem in the first case was that GCC started to parse the
|
|---|
| 365 | declaration of <code>b</code> as a function called <code>b</code> returning
|
|---|
| 366 | <code>B</code>, taking a function returning <code>A</code> as an argument.
|
|---|
| 367 | When it encountered the <code>1</code>, it was too late. To show the
|
|---|
| 368 | compiler that this should be really an expression, a comma operator with
|
|---|
| 369 | a dummy argument could be used:</p>
|
|---|
| 370 |
|
|---|
| 371 | <blockquote><pre>
|
|---|
| 372 | B b((0,A()),A(1));
|
|---|
| 373 | </pre></blockquote>
|
|---|
| 374 |
|
|---|
| 375 | <p>The work-around for simpler cases like the second one was to add
|
|---|
| 376 | additional parentheses around the expressions that were mistaken as
|
|---|
| 377 | declarations:</p>
|
|---|
| 378 |
|
|---|
| 379 | <blockquote><pre>
|
|---|
| 380 | (B(A(2))).foo();
|
|---|
| 381 | </pre></blockquote>
|
|---|
| 382 |
|
|---|
| 383 | <p>In the third case, however, additional parentheses were causing
|
|---|
| 384 | the problems: The compiler interpreted <code>A()</code> as a function
|
|---|
| 385 | (taking no arguments, returning <code>A</code>), and <code>(A())</code>
|
|---|
| 386 | as a cast lacking an expression to be casted, hence the parse error.
|
|---|
| 387 | The work-around was to omit the parentheses:</p>
|
|---|
| 388 |
|
|---|
| 389 | <blockquote><pre>
|
|---|
| 390 | return A();
|
|---|
| 391 | </pre></blockquote>
|
|---|
| 392 |
|
|---|
| 393 | <p>This problem occurred in a number of variants; in <code>throw</code>
|
|---|
| 394 | statements, people also frequently put the object in parentheses.</p></dd>
|
|---|
| 395 |
|
|---|
| 396 | </dl>
|
|---|
| 397 |
|
|---|
| 398 | <hr />
|
|---|
| 399 |
|
|---|
| 400 | <h2><a name="fortran">Fortran</a></h2>
|
|---|
| 401 |
|
|---|
| 402 | <p>Fortran bugs are documented in the G77 manual rather than
|
|---|
| 403 | explicitly listed here. Please see
|
|---|
| 404 | <a href="http://gcc.gnu.org/onlinedocs/g77/Trouble.html">Known Causes of
|
|---|
| 405 | Trouble with GNU Fortran</a> in the G77 manual.</p>
|
|---|
| 406 |
|
|---|
| 407 | <hr />
|
|---|
| 408 |
|
|---|
| 409 | <h1><a name="nonbugs">Non-bugs</a></h1>
|
|---|
| 410 |
|
|---|
| 411 | <p>The following are not actually bugs, but are reported often
|
|---|
| 412 | enough to warrant a mention here.</p>
|
|---|
| 413 |
|
|---|
| 414 | <p>It is not always a bug in the compiler, if code which "worked" in a
|
|---|
| 415 | previous version, is now rejected. Earlier versions of GCC sometimes were
|
|---|
| 416 | less picky about standard conformance and accepted invalid source code.
|
|---|
| 417 | In addition, programming languages themselves change, rendering code
|
|---|
| 418 | invalid that used to be conforming (this holds especially for C++).
|
|---|
| 419 | In either case, you should update your code to match recent language
|
|---|
| 420 | standards.</p>
|
|---|
| 421 |
|
|---|
| 422 | <hr />
|
|---|
| 423 |
|
|---|
| 424 | <h2><a name="nonbugs_general">General</a></h2>
|
|---|
| 425 |
|
|---|
| 426 | <dl>
|
|---|
| 427 | <dt>Problems with floating point numbers - the
|
|---|
| 428 | <a href="http://gcc.gnu.org/PR323">most often reported non-bug</a>.</dt>
|
|---|
| 429 | <dd><p>In a number of cases, GCC appears to perform floating point
|
|---|
| 430 | computations incorrectly. For example, the C++ program</p>
|
|---|
| 431 | <blockquote><pre>
|
|---|
| 432 | #include <iostream>
|
|---|
| 433 |
|
|---|
| 434 | int main()
|
|---|
| 435 | {
|
|---|
| 436 | double a = 0.5;
|
|---|
| 437 | double b = 0.01;
|
|---|
| 438 | std::cout << (int)(a / b) << std::endl;
|
|---|
| 439 | return 0;
|
|---|
| 440 | }
|
|---|
| 441 | </pre></blockquote>
|
|---|
| 442 | <p>might print 50 on some systems and optimization levels, and 49 on
|
|---|
| 443 | others.</p>
|
|---|
| 444 |
|
|---|
| 445 | <p>This is the result of <em>rounding</em>: The computer cannot
|
|---|
| 446 | represent all real numbers exactly, so it has to use
|
|---|
| 447 | approximations. When computing with approximation, the computer needs
|
|---|
| 448 | to round to the nearest representable number.</p>
|
|---|
| 449 |
|
|---|
| 450 | <p>This is not a bug in the compiler, but an inherent limitation of
|
|---|
| 451 | the floating point types. Please study
|
|---|
| 452 | <a href="http://www.validlab.com/goldberg/paper.ps">this paper</a>
|
|---|
| 453 | for more information.</p></dd>
|
|---|
| 454 | </dl>
|
|---|
| 455 |
|
|---|
| 456 | <hr />
|
|---|
| 457 |
|
|---|
| 458 | <h2><a name="nonbugs_c">C</a></h2>
|
|---|
| 459 |
|
|---|
| 460 | <dl>
|
|---|
| 461 | <dt>Increment/decrement operator (<code>++</code>/<code>--</code>) not
|
|---|
| 462 | working as expected - a <a href="http://gcc.gnu.org/PR11751">problem with
|
|---|
| 463 | many variations</a>.</dt>
|
|---|
| 464 |
|
|---|
| 465 | <dd><p>The following expressions have unpredictable results:</p>
|
|---|
| 466 | <blockquote><pre>
|
|---|
| 467 | x[i]=++i
|
|---|
| 468 | foo(i,++i)
|
|---|
| 469 | i*(++i) /* special case with foo=="operator*" */
|
|---|
| 470 | std::cout << i << ++i /* foo(foo(std::cout,i),++i) */
|
|---|
| 471 | </pre></blockquote>
|
|---|
| 472 | <p>since the <code>i</code> without increment can be evaluated before or
|
|---|
| 473 | after <code>++i</code>.</p>
|
|---|
| 474 |
|
|---|
| 475 | <p>The C and C++ standards have the notion of "sequence points". Everything
|
|---|
| 476 | that happens between two sequence points happens in an unspecified order,
|
|---|
| 477 | but it has to happen after the first and before the second sequence point.
|
|---|
| 478 | The end of a statement and a function call are examples for sequence points,
|
|---|
| 479 | whereas assignments and the comma between function arguments are not.</p>
|
|---|
| 480 |
|
|---|
| 481 | <p>Modifying a value twice between two sequence points as shown in the
|
|---|
| 482 | following examples is even worse:</p>
|
|---|
| 483 | <blockquote><pre>
|
|---|
| 484 | i=++i
|
|---|
| 485 | foo(++i,++i)
|
|---|
| 486 | (++i)*(++i) /* special case with foo=="operator*" */
|
|---|
| 487 | std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */
|
|---|
| 488 | </pre></blockquote>
|
|---|
| 489 | <p>This leads to undefined behavior (i.e. the compiler can do
|
|---|
| 490 | anything).</p></dd>
|
|---|
| 491 |
|
|---|
| 492 |
|
|---|
| 493 | <dt>Casting does not work as expected when optimization is turned on.</dt>
|
|---|
| 494 |
|
|---|
| 495 | <dd><p>This is often caused by a violation of aliasing rules, which are part
|
|---|
| 496 | of the ISO C standard. These rules say that a program is invalid if you try
|
|---|
| 497 | to access a variable through a pointer of an incompatible type. This is
|
|---|
| 498 | happening in the following example where a short is accessed through a
|
|---|
| 499 | pointer to integer (the code assumes 16-bit <code>short</code>s and 32-bit
|
|---|
| 500 | <code>int</code>s):</p>
|
|---|
| 501 | <blockquote><pre>
|
|---|
| 502 | #include <stdio.h>
|
|---|
| 503 |
|
|---|
| 504 | int main()
|
|---|
| 505 | {
|
|---|
| 506 | short a[2];
|
|---|
| 507 |
|
|---|
| 508 | a[0]=0x1111;
|
|---|
| 509 | a[1]=0x1111;
|
|---|
| 510 |
|
|---|
| 511 | *(int *)a = 0x22222222; /* violation of aliasing rules */
|
|---|
| 512 |
|
|---|
| 513 | printf("%x %x\n", a[0], a[1]);
|
|---|
| 514 | return 0;
|
|---|
| 515 | }
|
|---|
| 516 | </pre></blockquote>
|
|---|
| 517 | <p>The aliasing rules were designed to allow compilers more aggressive
|
|---|
| 518 | optimization. Basically, a compiler can assume that all changes to variables
|
|---|
| 519 | happen through pointers or references to variables of a type compatible to
|
|---|
| 520 | the accessed variable. Dereferencing a pointer that violates the aliasing
|
|---|
| 521 | rules results in undefined behavior.</p>
|
|---|
| 522 |
|
|---|
| 523 | <p>In the case above, the compiler may assume that no access through an
|
|---|
| 524 | integer pointer can change the array <code>a</code>, consisting of shorts.
|
|---|
| 525 | Thus, <code>printf</code> may be called with the original values of
|
|---|
| 526 | <code>a[0]</code> and <code>a[1]</code>. What really happens is up to
|
|---|
| 527 | the compiler and may change with architecture and optimization level.</p>
|
|---|
| 528 |
|
|---|
| 529 | <p>Recent versions of GCC turn on the option <code>-fstrict-aliasing</code>
|
|---|
| 530 | (which allows alias-based optimizations) by default with <code>-O2</code>.
|
|---|
| 531 | And some architectures then really print "1111 1111" as result. Without
|
|---|
| 532 | optimization the executable will generate the "expected" output
|
|---|
| 533 | "2222 2222".</p>
|
|---|
| 534 |
|
|---|
| 535 | <p>To disable optimizations based on alias-analysis for faulty legacy code,
|
|---|
| 536 | the option <code>-fno-strict-aliasing</code> can be used as a work-around.</p>
|
|---|
| 537 |
|
|---|
| 538 | <p>The option <code>-Wstrict-aliasing</code> (which is included in
|
|---|
| 539 | <code>-Wall</code>) warns about some - but not all - cases of violation
|
|---|
| 540 | of aliasing rules when <code>-fstrict-aliasing</code> is active.</p>
|
|---|
| 541 |
|
|---|
| 542 | <p>To fix the code above, you can use a <code>union</code> instead of a
|
|---|
| 543 | cast (note that this is a GCC extension which might not work with other
|
|---|
| 544 | compilers):</p>
|
|---|
| 545 | <blockquote><pre>
|
|---|
| 546 | #include <stdio.h>
|
|---|
| 547 |
|
|---|
| 548 | int main()
|
|---|
| 549 | {
|
|---|
| 550 | union
|
|---|
| 551 | {
|
|---|
| 552 | short a[2];
|
|---|
| 553 | int i;
|
|---|
| 554 | } u;
|
|---|
| 555 |
|
|---|
| 556 | u.a[0]=0x1111;
|
|---|
| 557 | u.a[1]=0x1111;
|
|---|
| 558 |
|
|---|
| 559 | u.i = 0x22222222;
|
|---|
| 560 |
|
|---|
| 561 | printf("%x %x\n", u.a[0], u.a[1]);
|
|---|
| 562 | return 0;
|
|---|
| 563 | }
|
|---|
| 564 | </pre></blockquote>
|
|---|
| 565 | <p>Now the result will always be "2222 2222".</p>
|
|---|
| 566 |
|
|---|
| 567 | <p>For some more insight into the subject, please have a look at
|
|---|
| 568 | <a href="http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html">this
|
|---|
| 569 | article</a>.</p></dd>
|
|---|
| 570 |
|
|---|
| 571 |
|
|---|
| 572 | <dt>Cannot use preprocessor directive in macro arguments.</dt>
|
|---|
| 573 | <dd><p>Let me guess... you used an older version of GCC to compile code
|
|---|
| 574 | that looks something like this:</p>
|
|---|
| 575 | <blockquote><pre>
|
|---|
| 576 | memcpy(dest, src,
|
|---|
| 577 | #ifdef PLATFORM1
|
|---|
| 578 | 12
|
|---|
| 579 | #else
|
|---|
| 580 | 24
|
|---|
| 581 | #endif
|
|---|
| 582 | );
|
|---|
| 583 | </pre></blockquote>
|
|---|
| 584 | <p>and you got a whole pile of error messages:</p>
|
|---|
| 585 | <blockquote><pre>
|
|---|
| 586 | test.c:11: warning: preprocessing directive not recognized within macro arg
|
|---|
| 587 | test.c:11: warning: preprocessing directive not recognized within macro arg
|
|---|
| 588 | test.c:11: warning: preprocessing directive not recognized within macro arg
|
|---|
| 589 | test.c: In function `foo':
|
|---|
| 590 | test.c:6: undefined or invalid # directive
|
|---|
| 591 | test.c:8: undefined or invalid # directive
|
|---|
| 592 | test.c:9: parse error before `24'
|
|---|
| 593 | test.c:10: undefined or invalid # directive
|
|---|
| 594 | </pre></blockquote>
|
|---|
| 595 |
|
|---|
| 596 | <p>This is because your C library's <code><string.h></code> happens
|
|---|
| 597 | to define <code>memcpy</code> as a macro - which is perfectly legitimate.
|
|---|
| 598 | In recent versions of glibc, for example, <code>printf</code> is among those
|
|---|
| 599 | functions which are implemented as macros.</p>
|
|---|
| 600 |
|
|---|
| 601 | <p>Versions of GCC prior to 3.3 did not allow you to put <code>#ifdef</code>
|
|---|
| 602 | (or any other preprocessor directive) inside the arguments of a macro. The
|
|---|
| 603 | code therefore would not compile.</p>
|
|---|
| 604 |
|
|---|
| 605 | <p>As of GCC 3.3 this kind of construct is always accepted and the
|
|---|
| 606 | preprocessor will probably do what you expect, but see the manual for
|
|---|
| 607 | detailed semantics.</p>
|
|---|
| 608 |
|
|---|
| 609 | <p>However, this kind of code is not portable. It is "undefined behavior"
|
|---|
| 610 | according to the C standard; that means different compilers may do
|
|---|
| 611 | different things with it. It is always possible to rewrite code which
|
|---|
| 612 | uses conditionals inside macros so that it doesn't. You could write
|
|---|
| 613 | the above example</p>
|
|---|
| 614 | <blockquote><pre>
|
|---|
| 615 | #ifdef PLATFORM1
|
|---|
| 616 | memcpy(dest, src, 12);
|
|---|
| 617 | #else
|
|---|
| 618 | memcpy(dest, src, 24);
|
|---|
| 619 | #endif
|
|---|
| 620 | </pre></blockquote>
|
|---|
| 621 | <p>This is a bit more typing, but I personally think it's better style
|
|---|
| 622 | in addition to being more portable.</p></dd>
|
|---|
| 623 |
|
|---|
| 624 |
|
|---|
| 625 | <dt>Cannot initialize a static variable with <code>stdin</code>.</dt>
|
|---|
| 626 | <dd><p>This has nothing to do with GCC, but people ask us about it a
|
|---|
| 627 | lot. Code like this:</p>
|
|---|
| 628 |
|
|---|
| 629 | <blockquote><pre>
|
|---|
| 630 | #include <stdio.h>
|
|---|
| 631 |
|
|---|
| 632 | FILE *yyin = stdin;
|
|---|
| 633 | </pre></blockquote>
|
|---|
| 634 |
|
|---|
| 635 | <p>will not compile with GNU libc, because <code>stdin</code> is not a
|
|---|
| 636 | constant. This was done deliberately, to make it easier to maintain
|
|---|
| 637 | binary compatibility when the type <code>FILE</code> needs to be changed.
|
|---|
| 638 | It is surprising for people used to traditional Unix C libraries, but it
|
|---|
| 639 | is permitted by the C standard.</p>
|
|---|
| 640 |
|
|---|
| 641 | <p>This construct commonly occurs in code generated by old versions of
|
|---|
| 642 | lex or yacc. We suggest you try regenerating the parser with a
|
|---|
| 643 | current version of flex or bison, respectively. In your own code, the
|
|---|
| 644 | appropriate fix is to move the initialization to the beginning of
|
|---|
| 645 | main.</p>
|
|---|
| 646 |
|
|---|
| 647 | <p>There is a common misconception that the GCC developers are
|
|---|
| 648 | responsible for GNU libc. These are in fact two entirely separate
|
|---|
| 649 | projects; please check the
|
|---|
| 650 | <a href="http://www.gnu.org/software/libc/">GNU libc web pages</a>
|
|---|
| 651 | for details.
|
|---|
| 652 | </p></dd>
|
|---|
| 653 | </dl>
|
|---|
| 654 |
|
|---|
| 655 | <hr />
|
|---|
| 656 |
|
|---|
| 657 | <h2><a name="nonbugs_cxx">C++</a></h2>
|
|---|
| 658 |
|
|---|
| 659 | <dl>
|
|---|
| 660 | <dt>Nested classes can access private members and types of the containing
|
|---|
| 661 | class.</dt>
|
|---|
| 662 |
|
|---|
| 663 | <dd><p>Defect report 45 clarifies that nested classes are members of the
|
|---|
| 664 | class they are nested in, and so are granted access to private members of
|
|---|
| 665 | that class.</p></dd>
|
|---|
| 666 |
|
|---|
| 667 | <dt>G++ emits two copies of constructors and destructors.</dt>
|
|---|
| 668 |
|
|---|
| 669 | <dd><p>In general there are <em>three</em> types of constructors (and
|
|---|
| 670 | destructors).</p>
|
|---|
| 671 | <ol>
|
|---|
| 672 | <li>The complete object constructor/destructor.</li>
|
|---|
| 673 | <li>The base object constructor/destructor.</li>
|
|---|
| 674 | <li>The allocating constructor/deallocating destructor.</li>
|
|---|
| 675 | </ol>
|
|---|
| 676 | <p>The first two are different, when virtual base classes are involved.
|
|---|
| 677 | </p></dd>
|
|---|
| 678 |
|
|---|
| 679 | <dt>Global destructors are not run in the correct order.</dt>
|
|---|
| 680 |
|
|---|
| 681 | <dd><p>Global destructors should be run in the reverse order of their
|
|---|
| 682 | constructors <em>completing</em>. In most cases this is the same as
|
|---|
| 683 | the reverse order of constructors <em>starting</em>, but sometimes it
|
|---|
| 684 | is different, and that is important. You need to compile and link your
|
|---|
| 685 | programs with <code>--use-cxa-atexit</code>. We have not turned this
|
|---|
| 686 | switch on by default, as it requires a <code>cxa</code> aware runtime
|
|---|
| 687 | library (<code>libc</code>, <code>glibc</code>, or equivalent).</p></dd>
|
|---|
| 688 |
|
|---|
| 689 | <dt>Classes in exception specifiers must be complete types.</dt>
|
|---|
| 690 |
|
|---|
| 691 | <dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or
|
|---|
| 692 | pointer to incomplete (other than <code><i>cv</i> void *</code>) in
|
|---|
| 693 | an exception specification.</p></dd>
|
|---|
| 694 |
|
|---|
| 695 | <dt>Exceptions don't work in multithreaded applications.</dt>
|
|---|
| 696 |
|
|---|
| 697 | <dd><p>You need to rebuild g++ and libstdc++ with
|
|---|
| 698 | <code>--enable-threads</code>. Remember, C++ exceptions are not like
|
|---|
| 699 | hardware interrupts. You cannot throw an exception in one thread and
|
|---|
| 700 | catch it in another. You cannot throw an exception from a signal
|
|---|
| 701 | handler and catch it in the main thread.</p></dd>
|
|---|
| 702 |
|
|---|
| 703 | <dt>Templates, scoping, and digraphs.</dt>
|
|---|
| 704 |
|
|---|
| 705 | <dd><p>If you have a class in the global namespace, say named <code>X</code>,
|
|---|
| 706 | and want to give it as a template argument to some other class, say
|
|---|
| 707 | <code>std::vector</code>, then <code>std::vector<::X></code>
|
|---|
| 708 | fails with a parser error.</p>
|
|---|
| 709 |
|
|---|
| 710 | <p>The reason is that the standard mandates that the sequence
|
|---|
| 711 | <code><:</code> is treated as if it were the token <code>[</code>.
|
|---|
| 712 | (There are several such combinations of characters - they are called
|
|---|
| 713 | <em>digraphs</em>.) Depending on the version, the compiler then reports
|
|---|
| 714 | a parse error before the character <code>:</code> (the colon before
|
|---|
| 715 | <code>X</code>) or a missing closing bracket <code>]</code>.</p>
|
|---|
| 716 |
|
|---|
| 717 | <p>The simplest way to avoid this is to write <code>std::vector<
|
|---|
| 718 | ::X></code>, i.e. place a space between the opening angle bracket
|
|---|
| 719 | and the scope operator.</p></dd>
|
|---|
| 720 |
|
|---|
| 721 |
|
|---|
| 722 | <dt><a name="cxx_rvalbind">Copy constructor access check while
|
|---|
| 723 | initializing a reference.</a></dt>
|
|---|
| 724 |
|
|---|
| 725 | <dd><p>Consider this code:</p>
|
|---|
| 726 |
|
|---|
| 727 | <blockquote><pre>
|
|---|
| 728 | class A
|
|---|
| 729 | {
|
|---|
| 730 | public:
|
|---|
| 731 | A();
|
|---|
| 732 |
|
|---|
| 733 | private:
|
|---|
| 734 | A(const A&); // private copy ctor
|
|---|
| 735 | };
|
|---|
| 736 |
|
|---|
| 737 | A makeA(void);
|
|---|
| 738 | void foo(const A&);
|
|---|
| 739 |
|
|---|
| 740 | void bar(void)
|
|---|
| 741 | {
|
|---|
| 742 | foo(A()); // error, copy ctor is not accessible
|
|---|
| 743 | foo(makeA()); // error, copy ctor is not accessible
|
|---|
| 744 |
|
|---|
| 745 | A a1;
|
|---|
| 746 | foo(a1); // OK, a1 is a lvalue
|
|---|
| 747 | }</pre></blockquote>
|
|---|
| 748 |
|
|---|
| 749 | <p>Starting with GCC 3.4.0, binding an rvalue to a const reference requires
|
|---|
| 750 | an accessible copy constructor. This might be surprising at first sight,
|
|---|
| 751 | especially since most popular compilers do not correctly implement this
|
|---|
| 752 | rule.</p>
|
|---|
| 753 |
|
|---|
| 754 | <p>The C++ Standard says that a temporary object should be created in
|
|---|
| 755 | this context and its contents filled with a copy of the object we are
|
|---|
| 756 | trying to bind to the reference; it also says that the temporary copy
|
|---|
| 757 | can be elided, but the semantic constraints (eg. accessibility) of the
|
|---|
| 758 | copy constructor still have to be checked.</p>
|
|---|
| 759 |
|
|---|
| 760 | <p>For further information, you can consult the following paragraphs of
|
|---|
| 761 | the C++ standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and
|
|---|
| 762 | [class.temporary]/2.</p></dd>
|
|---|
| 763 | </dl>
|
|---|
| 764 |
|
|---|
| 765 | <h3><a name="upgrading">Common problems when upgrading the compiler</a></h3>
|
|---|
| 766 |
|
|---|
| 767 | <h4>ABI changes</h4>
|
|---|
| 768 |
|
|---|
| 769 | <p>The C++ application binary interface (ABI) consists of two
|
|---|
| 770 | components: the first defines how the elements of classes are laid
|
|---|
| 771 | out, how functions are called, how function names are mangled, etc;
|
|---|
| 772 | the second part deals with the internals of the objects in libstdc++.
|
|---|
| 773 | Although we strive for a non-changing ABI, so far we have had to
|
|---|
| 774 | modify it with each major release. If you change your compiler to a
|
|---|
| 775 | different major release <em>you must recompile all libraries that
|
|---|
| 776 | contain C++ code</em>. If you fail to do so you risk getting linker
|
|---|
| 777 | errors or malfunctioning programs. Some of our Java support libraries
|
|---|
| 778 | also contain C++ code, so you might want to recompile all libraries to
|
|---|
| 779 | be safe. It should not be necessary to recompile if you have changed
|
|---|
| 780 | to a bug-fix release of the same version of the compiler; bug-fix
|
|---|
| 781 | releases are careful to avoid ABI changes. See also the
|
|---|
| 782 | <a href="onlinedocs/gcc/Compatibility.html">compatibility section</a>
|
|---|
| 783 | of the GCC manual.</p>
|
|---|
| 784 |
|
|---|
| 785 | <p>Remark: A major release is designated by a change to the first or second
|
|---|
| 786 | component of the two- or three-part version number. A minor (bug-fix)
|
|---|
| 787 | release is designated by a change to the third component only. Thus GCC
|
|---|
| 788 | 3.2 and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases
|
|---|
| 789 | for GCC 3.3. With the 3.4 series we are introducing a new naming scheme;
|
|---|
| 790 | the first release of this series is 3.4.0 instead of just 3.4.</p>
|
|---|
| 791 |
|
|---|
| 792 | <h4>Standard conformance</h4>
|
|---|
| 793 |
|
|---|
| 794 | <p>With each release, we try to make G++ conform closer to the ISO C++ standard
|
|---|
| 795 | (available at
|
|---|
| 796 | <a href="http://www.ncits.org/cplusplus.htm">http://www.ncits.org/cplusplus.htm</a>).
|
|---|
| 797 | We have also implemented some of the core and library defect reports
|
|---|
| 798 | (available at
|
|---|
| 799 | <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html">http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html</a>
|
|---|
| 800 | &
|
|---|
| 801 | <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html">http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html</a>
|
|---|
| 802 | respectively).</p>
|
|---|
| 803 |
|
|---|
| 804 | <p>Non-conforming legacy code that worked with older versions of GCC may be
|
|---|
| 805 | rejected by more recent compilers. There is no command-line switch to ensure
|
|---|
| 806 | compatibility in general, because trying to parse standard-conforming and
|
|---|
| 807 | old-style code at the same time would render the C++ frontend unmaintainable.
|
|---|
| 808 | However, some non-conforming constructs are allowed when the command-line
|
|---|
| 809 | option <code>-fpermissive</code> is used.</p>
|
|---|
| 810 |
|
|---|
| 811 | <p>Two milestones in standard conformance are GCC 3.0 (including a major
|
|---|
| 812 | overhaul of the standard library) and the 3.4.0 version (with its new C++
|
|---|
| 813 | parser).</p>
|
|---|
| 814 |
|
|---|
| 815 | <h4>New in GCC 3.0</h4>
|
|---|
| 816 |
|
|---|
| 817 | <ul>
|
|---|
| 818 |
|
|---|
| 819 | <li>The standard library is much more conformant, and uses the
|
|---|
| 820 | <code>std::</code> namespace (which is now a real namespace, not an
|
|---|
| 821 | alias for <code>::</code>).</li>
|
|---|
| 822 |
|
|---|
| 823 | <li>The standard header files for the c library don't end with
|
|---|
| 824 | <code>.h</code>, but begin with <code>c</code> (i.e.
|
|---|
| 825 | <code><cstdlib></code> rather than <code><stdlib.h></code>).
|
|---|
| 826 | The <code>.h</code> names are still available, but are deprecated.</li>
|
|---|
| 827 |
|
|---|
| 828 | <li><code><strstream></code> is deprecated, use
|
|---|
| 829 | <code><sstream></code> instead.</li>
|
|---|
| 830 |
|
|---|
| 831 | <li><code>streambuf::seekoff</code> &
|
|---|
| 832 | <code>streambuf::seekpos</code> are private, instead use
|
|---|
| 833 | <code>streambuf::pubseekoff</code> &
|
|---|
| 834 | <code>streambuf::pubseekpos</code> respectively.</li>
|
|---|
| 835 |
|
|---|
| 836 | <li>If <code>std::operator << (std::ostream &, long long)</code>
|
|---|
| 837 | doesn't exist, you need to recompile libstdc++ with
|
|---|
| 838 | <code>--enable-long-long</code>.</li>
|
|---|
| 839 |
|
|---|
| 840 | </ul>
|
|---|
| 841 |
|
|---|
| 842 | <p>If you get lots of errors about things like <code>cout</code> not being
|
|---|
| 843 | found, you've most likely forgotten to tell the compiler to look in the
|
|---|
| 844 | <code>std::</code> namespace. There are several ways to do this:</p>
|
|---|
| 845 |
|
|---|
| 846 | <ul>
|
|---|
| 847 |
|
|---|
| 848 | <li>Say <code>std::cout</code> at the call. This is the most explicit
|
|---|
| 849 | way of saying what you mean.</li>
|
|---|
| 850 |
|
|---|
| 851 | <li>Say <code>using std::cout;</code> somewhere before the call. You
|
|---|
| 852 | will need to do this for each function or type you wish to use from the
|
|---|
| 853 | standard library.</li>
|
|---|
| 854 |
|
|---|
| 855 | <li>Say <code>using namespace std;</code> somewhere before the call.
|
|---|
| 856 | This is the quick-but-dirty fix. This brings the <em>whole</em> of the
|
|---|
| 857 | <code>std::</code> namespace into scope. <em>Never</em> do this in a
|
|---|
| 858 | header file, as every user of your header file will be affected by this
|
|---|
| 859 | decision.</li>
|
|---|
| 860 |
|
|---|
| 861 | </ul>
|
|---|
| 862 |
|
|---|
| 863 | <h4><a name="new34">New in GCC 3.4.0</a></h4>
|
|---|
| 864 |
|
|---|
| 865 | <p>The new parser brings a lot of improvements, especially concerning
|
|---|
| 866 | name-lookup.</p>
|
|---|
| 867 |
|
|---|
| 868 | <ul>
|
|---|
| 869 |
|
|---|
| 870 | <li>The "implicit typename" extension got removed (it was already deprecated
|
|---|
| 871 | since GCC 3.1), so that the following code is now rejected, see [14.6]:
|
|---|
| 872 | <blockquote><pre>
|
|---|
| 873 | template <typename> struct A
|
|---|
| 874 | {
|
|---|
| 875 | typedef int X;
|
|---|
| 876 | };
|
|---|
| 877 |
|
|---|
| 878 | template <typename T> struct B
|
|---|
| 879 | {
|
|---|
| 880 | A<T>::X x; // error
|
|---|
| 881 | typename A<T>::X y; // OK
|
|---|
| 882 | };
|
|---|
| 883 |
|
|---|
| 884 | B<void> b;
|
|---|
| 885 | </pre></blockquote></li>
|
|---|
| 886 |
|
|---|
| 887 | <li>For similar reasons, the following code now requires the
|
|---|
| 888 | <code>template</code> keyword, see [14.2]:
|
|---|
| 889 | <blockquote><pre>
|
|---|
| 890 | template <typename> struct A
|
|---|
| 891 | {
|
|---|
| 892 | template <int> struct X {};
|
|---|
| 893 | };
|
|---|
| 894 |
|
|---|
| 895 | template <typename T> struct B
|
|---|
| 896 | {
|
|---|
| 897 | typename A<T>::X<0> x; // error
|
|---|
| 898 | typename A<T>::template X<0> y; // OK
|
|---|
| 899 | };
|
|---|
| 900 |
|
|---|
| 901 | B<void> b;
|
|---|
| 902 | </pre></blockquote></li>
|
|---|
| 903 |
|
|---|
| 904 | <li>We now have two-stage name-lookup, so that the following code is
|
|---|
| 905 | rejected, see [14.6]/9:
|
|---|
| 906 | <blockquote><pre>
|
|---|
| 907 | template <typename T> int foo()
|
|---|
| 908 | {
|
|---|
| 909 | return i; // error
|
|---|
| 910 | }
|
|---|
| 911 | </pre></blockquote></li>
|
|---|
| 912 |
|
|---|
| 913 | <li>This also affects members of base classes, see [14.6.2]:
|
|---|
| 914 | <blockquote><pre>
|
|---|
| 915 | template <typename> struct A
|
|---|
| 916 | {
|
|---|
| 917 | int i, j;
|
|---|
| 918 | };
|
|---|
| 919 |
|
|---|
| 920 | template <typename T> struct B : A<T>
|
|---|
| 921 | {
|
|---|
| 922 | int foo1() { return i; } // error
|
|---|
| 923 | int foo2() { return this->i; } // OK
|
|---|
| 924 | int foo3() { return B<T>::i; } // OK
|
|---|
| 925 | int foo4() { return A<T>::i; } // OK
|
|---|
| 926 |
|
|---|
| 927 | using A<T>::j;
|
|---|
| 928 | int foo5() { return j; } // OK
|
|---|
| 929 | };
|
|---|
| 930 | </pre></blockquote></li>
|
|---|
| 931 |
|
|---|
| 932 | </ul>
|
|---|
| 933 |
|
|---|
| 934 | <p>In addition to the problems listed above, the manual contains a section on
|
|---|
| 935 | <a href="http://gcc.gnu.org/onlinedocs/gcc/C---Misunderstandings.html">Common
|
|---|
| 936 | Misunderstandings with GNU C++</a>.</p>
|
|---|
| 937 |
|
|---|
| 938 | </body>
|
|---|
| 939 | </html>
|
|---|
