1c87b03e5Sespie<html> 2c87b03e5Sespie 3c87b03e5Sespie<head> 4c87b03e5Sespie<title>GCC Bugs</title> 5c87b03e5Sespie</head> 6c87b03e5Sespie 7c87b03e5Sespie<body> 8c87b03e5Sespie<h1>GCC Bugs</h1> 9c87b03e5Sespie 10c87b03e5Sespie<p>The latest version of this document is always available at 11c87b03e5Sespie<a href="http://gcc.gnu.org/bugs.html">http://gcc.gnu.org/bugs.html</a>.</p> 12c87b03e5Sespie 13c87b03e5Sespie<hr /> 14c87b03e5Sespie 15c87b03e5Sespie<h2>Table of Contents</h2> 16c87b03e5Sespie<ul> 17c87b03e5Sespie<li><a href="#report">Reporting Bugs</a> 18c87b03e5Sespie <ul> 19c87b03e5Sespie <li><a href="#need">What we need</a></li> 20c87b03e5Sespie <li><a href="#dontwant">What we DON'T want</a></li> 21c87b03e5Sespie <li><a href="#where">Where to post it</a></li> 22c87b03e5Sespie <li><a href="#detailed">Detailed bug reporting instructions</a></li> 23c87b03e5Sespie <li><a href="#gnat">Detailed bug reporting instructions for GNAT</a></li> 24c87b03e5Sespie <li><a href="#pch">Detailed bug reporting instructions when using a precompiled header</a></li> 25c87b03e5Sespie </ul> 26c87b03e5Sespie</li> 27c87b03e5Sespie<li><a href="#known">Frequently Reported Bugs in GCC</a> 28c87b03e5Sespie <ul> 29c87b03e5Sespie <li><a href="#cxx">C++</a> 30c87b03e5Sespie <ul> 31c87b03e5Sespie <li><a href="#missing">Missing features</a></li> 324e43c760Sespie <li><a href="#fixed34">Bugs fixed in the 3.4 series</a></li> 33c87b03e5Sespie </ul> 34c87b03e5Sespie </li> 35c87b03e5Sespie <li><a href="#fortran">Fortran</a></li> 36c87b03e5Sespie </ul> 37c87b03e5Sespie</li> 38c87b03e5Sespie<li><a href="#nonbugs">Non-bugs</a> 39c87b03e5Sespie <ul> 40c87b03e5Sespie <li><a href="#nonbugs_general">General</a></li> 41c87b03e5Sespie <li><a href="#nonbugs_c">C</a></li> 42c87b03e5Sespie <li><a href="#nonbugs_cxx">C++</a> 43c87b03e5Sespie <ul> 444e43c760Sespie <li><a href="#upgrading">Common problems when upgrading the compiler</a></li> 45c87b03e5Sespie </ul> 46c87b03e5Sespie </li> 47c87b03e5Sespie </ul> 48c87b03e5Sespie</li> 49c87b03e5Sespie</ul> 50c87b03e5Sespie 51c87b03e5Sespie<hr /> 52c87b03e5Sespie 53c87b03e5Sespie<h1><a name="report">Reporting Bugs</a></h1> 54c87b03e5Sespie 55c87b03e5Sespie<p>The main purpose of a bug report is to enable us to fix the bug. The 56c87b03e5Sespiemost important prerequisite for this is that the report must be complete and 57c87b03e5Sespieself-contained, which we explain in detail below.</p> 58c87b03e5Sespie 59c87b03e5Sespie<p>Before you report a bug, please check the 60c87b03e5Sespie<a href="#known">list of well-known bugs</a> and, <strong>if possible 61c87b03e5Sespiein any way, try a current development snapshot</strong>. 62c87b03e5SespieIf you want to report a bug with versions of GCC before 3.1 we strongly 63c87b03e5Sespierecommend upgrading to the current release first.</p> 64c87b03e5Sespie 65c87b03e5Sespie<p>Before reporting that GCC compiles your code incorrectly, please 66c87b03e5Sespiecompile it with <code>gcc -Wall</code> and see whether this shows 67c87b03e5Sespieanything wrong with your code that could be the cause instead of a bug 68c87b03e5Sespiein GCC.</p> 69c87b03e5Sespie 70c87b03e5Sespie<h2>Summarized bug reporting instructions</h2> 71c87b03e5Sespie 72c87b03e5Sespie<p>After this summary, you'll find detailed bug reporting 73c87b03e5Sespieinstructions, that explain how to obtain some of the information 74c87b03e5Sespierequested in this summary.</p> 75c87b03e5Sespie 76c87b03e5Sespie<h3><a name="need">What we need</a></h3> 77c87b03e5Sespie 78c87b03e5Sespie<p>Please include in your bug report all of the following items, the first 79c87b03e5Sespiethree of which can be obtained from the output of <code>gcc -v</code>:</p> 80c87b03e5Sespie 81c87b03e5Sespie<ul> 82c87b03e5Sespie <li>the exact version of GCC;</li> 83c87b03e5Sespie <li>the system type;</li> 84c87b03e5Sespie <li>the options given when GCC was configured/built;</li> 85c87b03e5Sespie <li>the complete command line that triggers the bug;</li> 86c87b03e5Sespie <li>the compiler output (error messages, warnings, etc.); and</li> 87c87b03e5Sespie <li>the <em>preprocessed</em> file (<code>*.i*</code>) that triggers the 88c87b03e5Sespie bug, generated by adding <code>-save-temps</code> to the complete 89c87b03e5Sespie compilation command, or, in the case of a bug report for the GNAT front end, 90c87b03e5Sespie a complete set of source files (see below).</li> 91c87b03e5Sespie</ul> 92c87b03e5Sespie 93c87b03e5Sespie<h3><a name="dontwant">What we do <strong>not</strong> want</a></h3> 94c87b03e5Sespie 95c87b03e5Sespie<ul> 96c87b03e5Sespie <li>A source file that <code>#include</code>s header files that are left 97c87b03e5Sespie out of the bug report (see above)</li> 98c87b03e5Sespie 99c87b03e5Sespie <li>That source file and a collection of header files.</li> 100c87b03e5Sespie 101c87b03e5Sespie <li>An attached archive (tar, zip, shar, whatever) containing all 102c87b03e5Sespie (or some :-) of the above.</li> 103c87b03e5Sespie 104c87b03e5Sespie <li>A code snippet that won't cause the compiler to produce the 105c87b03e5Sespie exact output mentioned in the bug report (e.g., a snippet with just 106c87b03e5Sespie a few lines around the one that <b>apparently</b> triggers the bug, 107c87b03e5Sespie with some pieces replaced with ellipses or comments for extra 108c87b03e5Sespie obfuscation :-)</li> 109c87b03e5Sespie 110c87b03e5Sespie <li>The location (URL) of the package that failed to build (we won't 111c87b03e5Sespie download it, anyway, since you've already given us what we need to 112c87b03e5Sespie duplicate the bug, haven't you? :-)</li> 113c87b03e5Sespie 114c87b03e5Sespie <li>An error that occurs only some of the times a certain file is 115c87b03e5Sespie compiled, such that retrying a sufficient number of times results in 116c87b03e5Sespie a successful compilation; this is a symptom of a hardware problem, 117c87b03e5Sespie not of a compiler bug (sorry)</li> 118c87b03e5Sespie 119c87b03e5Sespie <li>E-mail messages that complement previous, incomplete bug 120c87b03e5Sespie reports. Post a new, self-contained, full bug report instead, if 121c87b03e5Sespie possible as a follow-up to the original bug report</li> 122c87b03e5Sespie 123c87b03e5Sespie <li>Assembly files (<code>*.s</code>) produced by the compiler, or any 124c87b03e5Sespie binary files, such as object files, executables, core files, or 125c87b03e5Sespie precompiled header files</li> 126c87b03e5Sespie 127c87b03e5Sespie <li>Duplicate bug reports, or reports of bugs already fixed in the 128c87b03e5Sespie development tree, especially those that have already been reported 129c87b03e5Sespie as fixed last week :-)</li> 130c87b03e5Sespie 131c87b03e5Sespie <li>Bugs in the assembler, the linker or the C library. These are 132c87b03e5Sespie separate projects, with separate mailing lists and different bug 133c87b03e5Sespie reporting procedures</li> 134c87b03e5Sespie 135c87b03e5Sespie <li>Bugs in releases or snapshots of GCC not issued by the GNU 136c87b03e5Sespie Project. Report them to whoever provided you with the release</li> 137c87b03e5Sespie 138c87b03e5Sespie <li>Questions about the correctness or the expected behavior of 139c87b03e5Sespie certain constructs that are not GCC extensions. Ask them in forums 140c87b03e5Sespie dedicated to the discussion of the programming language</li> 141c87b03e5Sespie</ul> 142c87b03e5Sespie 143c87b03e5Sespie<h3><a name="where">Where to post it</a></h3> 144c87b03e5Sespie 145c87b03e5Sespie<p>Please submit your bug report directly to the 146c87b03e5Sespie<a href="http://gcc.gnu.org/bugzilla/">GCC bug database</a>. 147c87b03e5SespieAlternatively, you can use the <code>gccbug</code> script that mails your bug 148c87b03e5Sespiereport to the bug database. 1494e43c760Sespie<br /> 150c87b03e5SespieOnly if all this is absolutely impossible, mail all information to 1514e43c760Sespie<a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a>.</p> 152c87b03e5Sespie 153c87b03e5Sespie<h2><a name="detailed">Detailed bug reporting instructions</a></h2> 154c87b03e5Sespie 155c87b03e5Sespie<p>Please refer to the <a href="#gnat">next section</a> when reporting 156c87b03e5Sespiebugs in GNAT, the Ada compiler, or to the <a href="#pch">one after 157c87b03e5Sespiethat</a> when reporting bugs that appear when using a precompiled header.</p> 158c87b03e5Sespie 159c87b03e5Sespie<p>In general, all the information we need can be obtained by 160c87b03e5Sespiecollecting the command line below, as well as its output and the 161c87b03e5Sespiepreprocessed file it generates.</p> 162c87b03e5Sespie 163c87b03e5Sespie<blockquote><p><code>gcc -v -save-temps <i>all-your-options 164c87b03e5Sespiesource-file</i></code></p></blockquote> 165c87b03e5Sespie 166c87b03e5Sespie<p>Typically the preprocessed file (extension <code>.i</code> for C or 167c87b03e5Sespie<code>.ii</code> for C++, and <code>.f</code> if the preprocessor is used on 168c87b03e5SespieFortran files) will be large, so please compress the 169c87b03e5Sespieresulting file with one of the popular compression programs such as 170c87b03e5Sespiebzip2, gzip, zip or compress (in 171c87b03e5Sespiedecreasing order of preference). Use maximum compression 172c87b03e5Sespie(<code>-9</code>) if available. Please include the compressed 173c87b03e5Sespiepreprocessor output in your bug report, even if the source code is 174c87b03e5Sespiefreely available elsewhere; it makes the job of our volunteer testers 175c87b03e5Sespiemuch easier.</p> 176c87b03e5Sespie 177c87b03e5Sespie<p>The <b>only</b> excuses to not send us the preprocessed sources are 178c87b03e5Sespie(i) if you've found a bug in the preprocessor, (ii) if you've reduced 179c87b03e5Sespiethe testcase to a small file that doesn't include any other file or 180c87b03e5Sespie(iii) if the bug appears only when using precompiled headers. If you 181c87b03e5Sespiecan't post the preprocessed sources because they're proprietary code, 182c87b03e5Sespiethen try to create a small file that triggers the same problem.</p> 183c87b03e5Sespie 184c87b03e5Sespie<p>Since we're supposed to be able to re-create the assembly output 185c87b03e5Sespie(extension <code>.s</code>), you usually should not include 186c87b03e5Sespieit in the bug report, although you may want to post parts of it to 187c87b03e5Sespiepoint out assembly code you consider to be wrong.</p> 188c87b03e5Sespie 189c87b03e5Sespie<p>Whether to use MIME attachments or <code>uuencode</code> is up to 190c87b03e5Sespieyou. In any case, make sure the compiler command line, version and 191c87b03e5Sespieerror output are in plain text, so that we don't have to decode the 192c87b03e5Sespiebug report in order to tell who should take care of it. A meaningful 193c87b03e5Sespiesubject indicating language and platform also helps.</p> 194c87b03e5Sespie 195c87b03e5Sespie<p>Please avoid posting an archive (.tar, .shar or .zip); we generally 196c87b03e5Sespieneed just a single file to reproduce the bug (the .i/.ii/.f preprocessed 197c87b03e5Sespiefile), and, by storing it in an archive, you're just making our 198c87b03e5Sespievolunteers' jobs harder. Only when your bug report requires multiple 199c87b03e5Sespiesource files to be reproduced should you use an archive. This is, for example, 200c87b03e5Sespiethe case if you are using <code>INCLUDE</code> directives in Fortran code, 201c87b03e5Sespiewhich are not processed by the preprocessor, but the compiler. In that case, 202c87b03e5Sespiewe need the main file and all <code>INCLUDE</code>d files. In any case, 203c87b03e5Sespiemake sure the compiler version, error message, etc, are included in 204c87b03e5Sespiethe body of your bug report as plain text, even if needlessly 205c87b03e5Sespieduplicated as part of an archive.</p> 206c87b03e5Sespie 207c87b03e5Sespie<p>If you fail to supply enough information for a bug report to be 208c87b03e5Sespiereproduced, someone will probably ask you to post additional 209c87b03e5Sespieinformation (or just ignore your bug report, if they're in a bad day, 210c87b03e5Sespieso try to get it right on the first posting :-). In this case, please 211c87b03e5Sespiepost the additional information to the bug reporting mailing list, not 212c87b03e5Sespiejust to the person who requested it, unless explicitly told so. If 213c87b03e5Sespiepossible, please include in this follow-up all the information you had 214c87b03e5Sespiesupplied in the incomplete bug report (including the preprocessor 215c87b03e5Sespieoutput), so that the new bug report is self-contained.</p> 216c87b03e5Sespie 217c87b03e5Sespie<h2><a name="gnat">Detailed bug reporting instructions for GNAT</a></h2> 218c87b03e5Sespie 219c87b03e5Sespie<p>See the <a href="#detailed">previous section</a> for bug reporting 220c87b03e5Sespieinstructions for GCC language implementations other than Ada.</p> 221c87b03e5Sespie 222c87b03e5Sespie<p>Bug reports have to contain at least the following information in 223c87b03e5Sespieorder to be useful:</p> 224c87b03e5Sespie 225c87b03e5Sespie<ul> 226c87b03e5Sespie<li>the exact version of GCC, as shown by "<code>gcc -v</code>";</li> 227c87b03e5Sespie<li>the system type;</li> 228c87b03e5Sespie<li>the options when GCC was configured/built;</li> 229c87b03e5Sespie<li>the exact command line passed to the <code>gcc</code> program 230c87b03e5Sespietriggering the bug 231c87b03e5Sespie(not just the flags passed to <code>gnatmake</code>, but 232c87b03e5Sespie<code>gnatmake</code> prints the parameters it passed to <code>gcc</code>)</li> 233c87b03e5Sespie<li>a collection of source files for reproducing the bug, 234c87b03e5Sespiepreferably a minimal set (see below);</li> 235c87b03e5Sespie<li>a description of the expected behavior;</li> 236c87b03e5Sespie<li>a description of actual behavior.</li> 237c87b03e5Sespie</ul> 238c87b03e5Sespie 239c87b03e5Sespie<p>If your code depends on additional source files (usually package 240c87b03e5Sespiespecifications), submit the source code for these compilation units in 241c87b03e5Sespiea single file that is acceptable input to <code>gnatchop</code>, 242c87b03e5Sespiei.e. contains no non-Ada text. If the compilation terminated 243c87b03e5Sespienormally, you can usually obtain a list of dependencies using the 244c87b03e5Sespie"<code>gnatls -d <i>main_unit</i></code>" command, where 245c87b03e5Sespie<code><i>main_unit</i></code> is the file name of the main compilation 246c87b03e5Sespieunit (which is also passed to <code>gcc</code>).</p> 247c87b03e5Sespie 248c87b03e5Sespie<p>If you report a bug which causes the compiler to print a bug box, 249c87b03e5Sespieinclude that bug box in your report, and do not forget to send all the 250c87b03e5Sespiesource files listed after the bug box along with your report.</p> 251c87b03e5Sespie 252c87b03e5Sespie<p>If you use <code>gnatprep</code>, be sure to send in preprocessed 253c87b03e5Sespiesources (unless you have to report a bug in <code>gnatprep</code>).</p> 254c87b03e5Sespie 255c87b03e5Sespie<p>When you have checked that your report meets these criteria, please 256c87b03e5Sespiesubmit it according to our <a href="#where">generic instructions</a>. 257c87b03e5Sespie(If you use a mailing list for reporting, please include an 258c87b03e5Sespie"<code>[Ada]</code>" tag in the subject.)</p> 259c87b03e5Sespie 260c87b03e5Sespie<h2><a name="pch">Detailed bug reporting instructions when using a 261c87b03e5Sespieprecompiled header</a></h2> 262c87b03e5Sespie 263c87b03e5Sespie<p>If you're encountering a bug when using a precompiled header, the 264c87b03e5Sespiefirst thing to do is to delete the precompiled header, and try running 265c87b03e5Sespiethe same GCC command again. If the bug happens again, the bug doesn't 266c87b03e5Sespiereally involve precompiled headers, please report it without using 267c87b03e5Sespiethem by following the instructions <a href="#detailed">above</a>.</p> 268c87b03e5Sespie 269c87b03e5Sespie<p>If you've found a bug while <i>building</i> a precompiled header 270c87b03e5Sespie(for instance, the compiler crashes), follow the usual instructions 271c87b03e5Sespie<a href="#detailed">above</a>.</p> 272c87b03e5Sespie 273c87b03e5Sespie<p>If you've found a real precompiled header bug, what we'll need to 274c87b03e5Sespiereproduce it is the sources to build the precompiled header (as a 275c87b03e5Sespiesingle <code>.i</code> file), the source file that uses the 276c87b03e5Sespieprecompiled header, any other headers that source file includes, and 277c87b03e5Sespiethe command lines that you used to build the precompiled header and to 278c87b03e5Sespieuse it.</p> 279c87b03e5Sespie 280c87b03e5Sespie<p>Please <strong>don't</strong> send us the actual precompiled 281c87b03e5Sespieheader. It is likely to be very large and we can't use it to 282c87b03e5Sespiereproduce the problem.</p> 283c87b03e5Sespie 284c87b03e5Sespie<hr /> 285c87b03e5Sespie 286c87b03e5Sespie<h1><a name="known">Frequently Reported Bugs in GCC</a></h1> 287c87b03e5Sespie 288c87b03e5Sespie<p>This is a list of bugs in GCC that are reported very often, but not 289c87b03e5Sespieyet fixed. While it is certainly better to fix bugs instead of documenting 290c87b03e5Sespiethem, this document might save people the effort of writing a bug report 291c87b03e5Sespiewhen the bug is already well-known.</p> 292c87b03e5Sespie 293c87b03e5Sespie<p>There are many reasons why a reported bug doesn't get fixed. 294c87b03e5SespieIt might be difficult to fix, or fixing it might break compatibility. 295c87b03e5SespieOften, reports get a low priority when there is a simple work-around. 296c87b03e5SespieIn particular, bugs caused by invalid code have a simple work-around: 297c87b03e5Sespie<em>fix the code</em>.</p> 298c87b03e5Sespie 299c87b03e5Sespie<hr /> 300c87b03e5Sespie 301c87b03e5Sespie<h2><a name="cxx">C++</a></h2> 302c87b03e5Sespie 303c87b03e5Sespie<h3><a name="missing">Missing features</a></h3> 304c87b03e5Sespie 305c87b03e5Sespie<dl> 306c87b03e5Sespie 307c87b03e5Sespie<dt>The <code>export</code> keyword is not implemented.</dt> 308c87b03e5Sespie<dd><p>Most C++ compilers (G++ included) do not yet implement 309c87b03e5Sespie<code>export</code>, which is necessary for separate compilation of 310c87b03e5Sespietemplate declarations and definitions. Without <code>export</code>, a 311c87b03e5Sespietemplate definition must be in scope to be used. The obvious 312c87b03e5Sespieworkaround is simply to place all definitions in the header 313c87b03e5Sespieitself. Alternatively, the compilation unit containing template 314c87b03e5Sespiedefinitions may be included from the header.</p></dd> 315c87b03e5Sespie 316c87b03e5Sespie</dl> 317c87b03e5Sespie 3184e43c760Sespie<h3><a name="fixed34">Bugs fixed in the 3.4 series</a></h3> 319c87b03e5Sespie 3204e43c760Sespie<p>The following bugs are present up to (and including) GCC 3.3.x. 3214e43c760SespieThey have been fixed in 3.4.0.</p> 322c87b03e5Sespie 3234e43c760Sespie<dl> 3244e43c760Sespie 3254e43c760Sespie<dt>Two-stage name-lookup.</dt> 3264e43c760Sespie 3274e43c760Sespie<dd><p>GCC did not implement two-stage name-lookup (also see 3284e43c760Sespie<a href="#new34">below</a>).</p></dd> 3294e43c760Sespie 3304e43c760Sespie<dt>Covariant return types.</dt> 3314e43c760Sespie 3324e43c760Sespie<dd><p>GCC did not implement non-trivial covariant returns.</p></dd> 3334e43c760Sespie 3344e43c760Sespie<dt>Parse errors for "simple" code.</dt> 3354e43c760Sespie 3364e43c760Sespie<dd><p>GCC gave parse errors for seemingly simple code, such as</p> 3374e43c760Sespie 3384e43c760Sespie<blockquote><pre> 3394e43c760Sespiestruct A 3404e43c760Sespie{ 341c87b03e5Sespie A(); 342c87b03e5Sespie A(int); 343c87b03e5Sespie}; 344c87b03e5Sespie 3454e43c760Sespiestruct B 3464e43c760Sespie{ 347c87b03e5Sespie B(A); 348c87b03e5Sespie B(A,A); 3494e43c760Sespie void foo(); 350c87b03e5Sespie}; 351c87b03e5Sespie 3524e43c760SespieA bar() 3534e43c760Sespie{ 354c87b03e5Sespie B b(A(),A(1)); // Variable b, initialized with two temporaries 3554e43c760Sespie B(A(2)).foo(); // B temporary, initialized with A temporary 3564e43c760Sespie return (A()); // return A temporary 357c87b03e5Sespie} 3584e43c760Sespie</pre></blockquote> 359c87b03e5Sespie 3604e43c760Sespie<p>Although being valid code, each of the three lines with a comment was 3614e43c760Sespierejected by GCC. The work-arounds for older compiler versions proposed 3624e43c760Sespiebelow do not change the semantics of the programs at all.</p> 3634e43c760Sespie 3644e43c760Sespie<p>The problem in the first case was that GCC started to parse the 3654e43c760Sespiedeclaration of <code>b</code> as a function called <code>b</code> returning 3664e43c760Sespie<code>B</code>, taking a function returning <code>A</code> as an argument. 3674e43c760SespieWhen it encountered the <code>1</code>, it was too late. To show the 3684e43c760Sespiecompiler that this should be really an expression, a comma operator with 3694e43c760Sespiea dummy argument could be used:</p> 3704e43c760Sespie 3714e43c760Sespie<blockquote><pre> 3724e43c760SespieB b((0,A()),A(1)); 3734e43c760Sespie</pre></blockquote> 3744e43c760Sespie 3754e43c760Sespie<p>The work-around for simpler cases like the second one was to add 3764e43c760Sespieadditional parentheses around the expressions that were mistaken as 377c87b03e5Sespiedeclarations:</p> 378c87b03e5Sespie 3794e43c760Sespie<blockquote><pre> 3804e43c760Sespie(B(A(2))).foo(); 3814e43c760Sespie</pre></blockquote> 382c87b03e5Sespie 3834e43c760Sespie<p>In the third case, however, additional parentheses were causing 3844e43c760Sespiethe problems: The compiler interpreted <code>A()</code> as a function 3854e43c760Sespie(taking no arguments, returning <code>A</code>), and <code>(A())</code> 3864e43c760Sespieas a cast lacking an expression to be casted, hence the parse error. 3874e43c760SespieThe work-around was to omit the parentheses:</p> 388c87b03e5Sespie 3894e43c760Sespie<blockquote><pre> 390c87b03e5Sespiereturn A(); 3914e43c760Sespie</pre></blockquote> 392c87b03e5Sespie 3934e43c760Sespie<p>This problem occurred in a number of variants; in <code>throw</code> 3944e43c760Sespiestatements, people also frequently put the object in parentheses.</p></dd> 3954e43c760Sespie 3964e43c760Sespie</dl> 397c87b03e5Sespie 398c87b03e5Sespie<hr /> 399c87b03e5Sespie 400c87b03e5Sespie<h2><a name="fortran">Fortran</a></h2> 401c87b03e5Sespie 402c87b03e5Sespie<p>Fortran bugs are documented in the G77 manual rather than 403c87b03e5Sespieexplicitly listed here. Please see 404c87b03e5Sespie<a href="http://gcc.gnu.org/onlinedocs/g77/Trouble.html">Known Causes of 405c87b03e5SespieTrouble with GNU Fortran</a> in the G77 manual.</p> 406c87b03e5Sespie 407c87b03e5Sespie<hr /> 408c87b03e5Sespie 409c87b03e5Sespie<h1><a name="nonbugs">Non-bugs</a></h1> 410c87b03e5Sespie 411c87b03e5Sespie<p>The following are not actually bugs, but are reported often 412c87b03e5Sespieenough to warrant a mention here.</p> 413c87b03e5Sespie 414c87b03e5Sespie<p>It is not always a bug in the compiler, if code which "worked" in a 415c87b03e5Sespieprevious version, is now rejected. Earlier versions of GCC sometimes were 416c87b03e5Sespieless picky about standard conformance and accepted invalid source code. 417c87b03e5SespieIn addition, programming languages themselves change, rendering code 418c87b03e5Sespieinvalid that used to be conforming (this holds especially for C++). 419c87b03e5SespieIn either case, you should update your code to match recent language 420c87b03e5Sespiestandards.</p> 421c87b03e5Sespie 422c87b03e5Sespie<hr /> 423c87b03e5Sespie 424c87b03e5Sespie<h2><a name="nonbugs_general">General</a></h2> 425c87b03e5Sespie 426c87b03e5Sespie<dl> 427c87b03e5Sespie<dt>Problems with floating point numbers - the 428c87b03e5Sespie<a href="http://gcc.gnu.org/PR323">most often reported non-bug</a>.</dt> 429c87b03e5Sespie<dd><p>In a number of cases, GCC appears to perform floating point 430c87b03e5Sespiecomputations incorrectly. For example, the C++ program</p> 431c87b03e5Sespie<blockquote><pre> 432c87b03e5Sespie#include <iostream> 433c87b03e5Sespie 434c87b03e5Sespieint main() 435c87b03e5Sespie{ 436c87b03e5Sespie double a = 0.5; 437c87b03e5Sespie double b = 0.01; 438c87b03e5Sespie std::cout << (int)(a / b) << std::endl; 439c87b03e5Sespie return 0; 440c87b03e5Sespie} 441c87b03e5Sespie</pre></blockquote> 442c87b03e5Sespie<p>might print 50 on some systems and optimization levels, and 49 on 443c87b03e5Sespieothers.</p> 444c87b03e5Sespie 4454e43c760Sespie<p>This is the result of <em>rounding</em>: The computer cannot 446c87b03e5Sespierepresent all real numbers exactly, so it has to use 447c87b03e5Sespieapproximations. When computing with approximation, the computer needs 448c87b03e5Sespieto round to the nearest representable number.</p> 449c87b03e5Sespie 450c87b03e5Sespie<p>This is not a bug in the compiler, but an inherent limitation of 451c87b03e5Sespiethe floating point types. Please study 452c87b03e5Sespie<a href="http://www.validlab.com/goldberg/paper.ps">this paper</a> 453c87b03e5Sespiefor more information.</p></dd> 454c87b03e5Sespie</dl> 455c87b03e5Sespie 456c87b03e5Sespie<hr /> 457c87b03e5Sespie 458c87b03e5Sespie<h2><a name="nonbugs_c">C</a></h2> 459c87b03e5Sespie 460c87b03e5Sespie<dl> 4614e43c760Sespie<dt>Increment/decrement operator (<code>++</code>/<code>--</code>) not 4624e43c760Sespieworking as expected - a <a href="http://gcc.gnu.org/PR11751">problem with 4634e43c760Sespiemany variations</a>.</dt> 4644e43c760Sespie 4654e43c760Sespie<dd><p>The following expressions have unpredictable results:</p> 4664e43c760Sespie<blockquote><pre> 4674e43c760Sespiex[i]=++i 4684e43c760Sespiefoo(i,++i) 4694e43c760Sespiei*(++i) /* special case with foo=="operator*" */ 4704e43c760Sespiestd::cout << i << ++i /* foo(foo(std::cout,i),++i) */ 4714e43c760Sespie</pre></blockquote> 4724e43c760Sespie<p>since the <code>i</code> without increment can be evaluated before or 4734e43c760Sespieafter <code>++i</code>.</p> 4744e43c760Sespie 4754e43c760Sespie<p>The C and C++ standards have the notion of "sequence points". Everything 4764e43c760Sespiethat happens between two sequence points happens in an unspecified order, 4774e43c760Sespiebut it has to happen after the first and before the second sequence point. 4784e43c760SespieThe end of a statement and a function call are examples for sequence points, 4794e43c760Sespiewhereas assignments and the comma between function arguments are not.</p> 4804e43c760Sespie 4814e43c760Sespie<p>Modifying a value twice between two sequence points as shown in the 4824e43c760Sespiefollowing examples is even worse:</p> 4834e43c760Sespie<blockquote><pre> 4844e43c760Sespiei=++i 4854e43c760Sespiefoo(++i,++i) 4864e43c760Sespie(++i)*(++i) /* special case with foo=="operator*" */ 4874e43c760Sespiestd::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */ 4884e43c760Sespie</pre></blockquote> 4894e43c760Sespie<p>This leads to undefined behavior (i.e. the compiler can do 4904e43c760Sespieanything).</p></dd> 4914e43c760Sespie 4924e43c760Sespie 493c87b03e5Sespie<dt>Casting does not work as expected when optimization is turned on.</dt> 494c87b03e5Sespie 495c87b03e5Sespie<dd><p>This is often caused by a violation of aliasing rules, which are part 496c87b03e5Sespieof the ISO C standard. These rules say that a program is invalid if you try 497c87b03e5Sespieto access a variable through a pointer of an incompatible type. This is 498c87b03e5Sespiehappening in the following example where a short is accessed through a 499c87b03e5Sespiepointer to integer (the code assumes 16-bit <code>short</code>s and 32-bit 500c87b03e5Sespie<code>int</code>s):</p> 501c87b03e5Sespie<blockquote><pre> 502c87b03e5Sespie#include <stdio.h> 503c87b03e5Sespie 504c87b03e5Sespieint main() 505c87b03e5Sespie{ 506c87b03e5Sespie short a[2]; 507c87b03e5Sespie 508c87b03e5Sespie a[0]=0x1111; 509c87b03e5Sespie a[1]=0x1111; 510c87b03e5Sespie 511c87b03e5Sespie *(int *)a = 0x22222222; /* violation of aliasing rules */ 512c87b03e5Sespie 513c87b03e5Sespie printf("%x %x\n", a[0], a[1]); 514c87b03e5Sespie return 0; 515c87b03e5Sespie} 516c87b03e5Sespie</pre></blockquote> 517c87b03e5Sespie<p>The aliasing rules were designed to allow compilers more aggressive 518c87b03e5Sespieoptimization. Basically, a compiler can assume that all changes to variables 519c87b03e5Sespiehappen through pointers or references to variables of a type compatible to 520c87b03e5Sespiethe accessed variable. Dereferencing a pointer that violates the aliasing 521c87b03e5Sespierules results in undefined behavior.</p> 522c87b03e5Sespie 523c87b03e5Sespie<p>In the case above, the compiler may assume that no access through an 524c87b03e5Sespieinteger pointer can change the array <code>a</code>, consisting of shorts. 525c87b03e5SespieThus, <code>printf</code> may be called with the original values of 526c87b03e5Sespie<code>a[0]</code> and <code>a[1]</code>. What really happens is up to 527c87b03e5Sespiethe compiler and may change with architecture and optimization level.</p> 528c87b03e5Sespie 529c87b03e5Sespie<p>Recent versions of GCC turn on the option <code>-fstrict-aliasing</code> 530c87b03e5Sespie(which allows alias-based optimizations) by default with <code>-O2</code>. 531c87b03e5SespieAnd some architectures then really print "1111 1111" as result. Without 532c87b03e5Sespieoptimization the executable will generate the "expected" output 533c87b03e5Sespie"2222 2222".</p> 534c87b03e5Sespie 535c87b03e5Sespie<p>To disable optimizations based on alias-analysis for faulty legacy code, 536c87b03e5Sespiethe option <code>-fno-strict-aliasing</code> can be used as a work-around.</p> 537c87b03e5Sespie 538c87b03e5Sespie<p>The option <code>-Wstrict-aliasing</code> (which is included in 539c87b03e5Sespie<code>-Wall</code>) warns about some - but not all - cases of violation 540c87b03e5Sespieof aliasing rules when <code>-fstrict-aliasing</code> is active.</p> 541c87b03e5Sespie 542c87b03e5Sespie<p>To fix the code above, you can use a <code>union</code> instead of a 543c87b03e5Sespiecast (note that this is a GCC extension which might not work with other 544c87b03e5Sespiecompilers):</p> 545c87b03e5Sespie<blockquote><pre> 546c87b03e5Sespie#include <stdio.h> 547c87b03e5Sespie 548c87b03e5Sespieint main() 549c87b03e5Sespie{ 550c87b03e5Sespie union 551c87b03e5Sespie { 552c87b03e5Sespie short a[2]; 553c87b03e5Sespie int i; 554c87b03e5Sespie } u; 555c87b03e5Sespie 556c87b03e5Sespie u.a[0]=0x1111; 557c87b03e5Sespie u.a[1]=0x1111; 558c87b03e5Sespie 559c87b03e5Sespie u.i = 0x22222222; 560c87b03e5Sespie 561c87b03e5Sespie printf("%x %x\n", u.a[0], u.a[1]); 562c87b03e5Sespie return 0; 563c87b03e5Sespie} 564c87b03e5Sespie</pre></blockquote> 565c87b03e5Sespie<p>Now the result will always be "2222 2222".</p> 566c87b03e5Sespie 567c87b03e5Sespie<p>For some more insight into the subject, please have a look at 568c87b03e5Sespie<a href="http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html">this 569c87b03e5Sespiearticle</a>.</p></dd> 570c87b03e5Sespie 571c87b03e5Sespie 572c87b03e5Sespie<dt>Cannot use preprocessor directive in macro arguments.</dt> 573c87b03e5Sespie<dd><p>Let me guess... you used an older version of GCC to compile code 574c87b03e5Sespiethat looks something like this:</p> 575c87b03e5Sespie<blockquote><pre> 576c87b03e5Sespie memcpy(dest, src, 577c87b03e5Sespie#ifdef PLATFORM1 578c87b03e5Sespie 12 579c87b03e5Sespie#else 580c87b03e5Sespie 24 581c87b03e5Sespie#endif 582c87b03e5Sespie ); 583c87b03e5Sespie</pre></blockquote> 584c87b03e5Sespie<p>and you got a whole pile of error messages:</p> 585c87b03e5Sespie<blockquote><pre> 586c87b03e5Sespietest.c:11: warning: preprocessing directive not recognized within macro arg 587c87b03e5Sespietest.c:11: warning: preprocessing directive not recognized within macro arg 588c87b03e5Sespietest.c:11: warning: preprocessing directive not recognized within macro arg 589c87b03e5Sespietest.c: In function `foo': 590c87b03e5Sespietest.c:6: undefined or invalid # directive 591c87b03e5Sespietest.c:8: undefined or invalid # directive 592c87b03e5Sespietest.c:9: parse error before `24' 593c87b03e5Sespietest.c:10: undefined or invalid # directive 594c87b03e5Sespie</pre></blockquote> 595c87b03e5Sespie 596c87b03e5Sespie<p>This is because your C library's <code><string.h></code> happens 597c87b03e5Sespieto define <code>memcpy</code> as a macro - which is perfectly legitimate. 598c87b03e5SespieIn recent versions of glibc, for example, <code>printf</code> is among those 599c87b03e5Sespiefunctions which are implemented as macros.</p> 600c87b03e5Sespie 601c87b03e5Sespie<p>Versions of GCC prior to 3.3 did not allow you to put <code>#ifdef</code> 602c87b03e5Sespie(or any other preprocessor directive) inside the arguments of a macro. The 603c87b03e5Sespiecode therefore would not compile.</p> 604c87b03e5Sespie 605c87b03e5Sespie<p>As of GCC 3.3 this kind of construct is always accepted and the 606c87b03e5Sespiepreprocessor will probably do what you expect, but see the manual for 607c87b03e5Sespiedetailed semantics.</p> 608c87b03e5Sespie 609c87b03e5Sespie<p>However, this kind of code is not portable. It is "undefined behavior" 610c87b03e5Sespieaccording to the C standard; that means different compilers may do 611c87b03e5Sespiedifferent things with it. It is always possible to rewrite code which 612c87b03e5Sespieuses conditionals inside macros so that it doesn't. You could write 613c87b03e5Sespiethe above example</p> 614c87b03e5Sespie<blockquote><pre> 615c87b03e5Sespie#ifdef PLATFORM1 616c87b03e5Sespie memcpy(dest, src, 12); 617c87b03e5Sespie#else 618c87b03e5Sespie memcpy(dest, src, 24); 619c87b03e5Sespie#endif 620c87b03e5Sespie</pre></blockquote> 621c87b03e5Sespie<p>This is a bit more typing, but I personally think it's better style 622c87b03e5Sespiein addition to being more portable.</p></dd> 623c87b03e5Sespie 624c87b03e5Sespie 625c87b03e5Sespie<dt>Cannot initialize a static variable with <code>stdin</code>.</dt> 626c87b03e5Sespie<dd><p>This has nothing to do with GCC, but people ask us about it a 627c87b03e5Sespielot. Code like this:</p> 628c87b03e5Sespie 629c87b03e5Sespie<blockquote><pre> 630c87b03e5Sespie#include <stdio.h> 631c87b03e5Sespie 632c87b03e5SespieFILE *yyin = stdin; 633c87b03e5Sespie</pre></blockquote> 634c87b03e5Sespie 635c87b03e5Sespie<p>will not compile with GNU libc, because <code>stdin</code> is not a 636c87b03e5Sespieconstant. This was done deliberately, to make it easier to maintain 637c87b03e5Sespiebinary compatibility when the type <code>FILE</code> needs to be changed. 638c87b03e5SespieIt is surprising for people used to traditional Unix C libraries, but it 639c87b03e5Sespieis permitted by the C standard.</p> 640c87b03e5Sespie 641c87b03e5Sespie<p>This construct commonly occurs in code generated by old versions of 642c87b03e5Sespielex or yacc. We suggest you try regenerating the parser with a 643c87b03e5Sespiecurrent version of flex or bison, respectively. In your own code, the 644c87b03e5Sespieappropriate fix is to move the initialization to the beginning of 645c87b03e5Sespiemain.</p> 646c87b03e5Sespie 647c87b03e5Sespie<p>There is a common misconception that the GCC developers are 648c87b03e5Sespieresponsible for GNU libc. These are in fact two entirely separate 649c87b03e5Sespieprojects; please check the 6504e43c760Sespie<a href="http://www.gnu.org/software/libc/">GNU libc web pages</a> 651c87b03e5Sespiefor details. 652c87b03e5Sespie</p></dd> 653c87b03e5Sespie</dl> 654c87b03e5Sespie 655c87b03e5Sespie<hr /> 656c87b03e5Sespie 657c87b03e5Sespie<h2><a name="nonbugs_cxx">C++</a></h2> 658c87b03e5Sespie 659c87b03e5Sespie<dl> 660c87b03e5Sespie<dt>Nested classes can access private members and types of the containing 661c87b03e5Sespieclass.</dt> 662c87b03e5Sespie 663c87b03e5Sespie<dd><p>Defect report 45 clarifies that nested classes are members of the 664c87b03e5Sespieclass they are nested in, and so are granted access to private members of 665c87b03e5Sespiethat class.</p></dd> 666c87b03e5Sespie 667c87b03e5Sespie<dt>G++ emits two copies of constructors and destructors.</dt> 668c87b03e5Sespie 669c87b03e5Sespie<dd><p>In general there are <em>three</em> types of constructors (and 670c87b03e5Sespiedestructors).</p> 671c87b03e5Sespie<ol> 672c87b03e5Sespie<li>The complete object constructor/destructor.</li> 673c87b03e5Sespie<li>The base object constructor/destructor.</li> 674c87b03e5Sespie<li>The allocating constructor/deallocating destructor.</li> 675c87b03e5Sespie</ol> 676c87b03e5Sespie<p>The first two are different, when virtual base classes are involved. 677c87b03e5Sespie</p></dd> 678c87b03e5Sespie 679c87b03e5Sespie<dt>Global destructors are not run in the correct order.</dt> 680c87b03e5Sespie 681c87b03e5Sespie<dd><p>Global destructors should be run in the reverse order of their 682c87b03e5Sespieconstructors <em>completing</em>. In most cases this is the same as 683c87b03e5Sespiethe reverse order of constructors <em>starting</em>, but sometimes it 684c87b03e5Sespieis different, and that is important. You need to compile and link your 685c87b03e5Sespieprograms with <code>--use-cxa-atexit</code>. We have not turned this 686c87b03e5Sespieswitch on by default, as it requires a <code>cxa</code> aware runtime 687c87b03e5Sespielibrary (<code>libc</code>, <code>glibc</code>, or equivalent).</p></dd> 688c87b03e5Sespie 689c87b03e5Sespie<dt>Classes in exception specifiers must be complete types.</dt> 690c87b03e5Sespie 691c87b03e5Sespie<dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or 692c87b03e5Sespiepointer to incomplete (other than <code><i>cv</i> void *</code>) in 693c87b03e5Sespiean exception specification.</p></dd> 694c87b03e5Sespie 695c87b03e5Sespie<dt>Exceptions don't work in multithreaded applications.</dt> 696c87b03e5Sespie 697c87b03e5Sespie<dd><p>You need to rebuild g++ and libstdc++ with 698c87b03e5Sespie<code>--enable-threads</code>. Remember, C++ exceptions are not like 699c87b03e5Sespiehardware interrupts. You cannot throw an exception in one thread and 700c87b03e5Sespiecatch it in another. You cannot throw an exception from a signal 701c87b03e5Sespiehandler and catch it in the main thread.</p></dd> 702c87b03e5Sespie 703c87b03e5Sespie<dt>Templates, scoping, and digraphs.</dt> 704c87b03e5Sespie 705c87b03e5Sespie<dd><p>If you have a class in the global namespace, say named <code>X</code>, 706c87b03e5Sespieand want to give it as a template argument to some other class, say 707c87b03e5Sespie<code>std::vector</code>, then <code>std::vector<::X></code> 708c87b03e5Sespiefails with a parser error.</p> 709c87b03e5Sespie 710c87b03e5Sespie<p>The reason is that the standard mandates that the sequence 711c87b03e5Sespie<code><:</code> is treated as if it were the token <code>[</code>. 712c87b03e5Sespie(There are several such combinations of characters - they are called 713c87b03e5Sespie<em>digraphs</em>.) Depending on the version, the compiler then reports 714c87b03e5Sespiea parse error before the character <code>:</code> (the colon before 715c87b03e5Sespie<code>X</code>) or a missing closing bracket <code>]</code>.</p> 716c87b03e5Sespie 717c87b03e5Sespie<p>The simplest way to avoid this is to write <code>std::vector< 718c87b03e5Sespie::X></code>, i.e. place a space between the opening angle bracket 719c87b03e5Sespieand the scope operator.</p></dd> 7204e43c760Sespie 7214e43c760Sespie 7224e43c760Sespie<dt><a name="cxx_rvalbind">Copy constructor access check while 7234e43c760Sespieinitializing a reference.</a></dt> 7244e43c760Sespie 7254e43c760Sespie<dd><p>Consider this code:</p> 7264e43c760Sespie 7274e43c760Sespie<blockquote><pre> 7284e43c760Sespieclass A 7294e43c760Sespie{ 7304e43c760Sespiepublic: 7314e43c760Sespie A(); 7324e43c760Sespie 7334e43c760Sespieprivate: 7344e43c760Sespie A(const A&); // private copy ctor 7354e43c760Sespie}; 7364e43c760Sespie 7374e43c760SespieA makeA(void); 7384e43c760Sespievoid foo(const A&); 7394e43c760Sespie 7404e43c760Sespievoid bar(void) 7414e43c760Sespie{ 7424e43c760Sespie foo(A()); // error, copy ctor is not accessible 7434e43c760Sespie foo(makeA()); // error, copy ctor is not accessible 7444e43c760Sespie 7454e43c760Sespie A a1; 7464e43c760Sespie foo(a1); // OK, a1 is a lvalue 7474e43c760Sespie}</pre></blockquote> 7484e43c760Sespie 7494e43c760Sespie<p>Starting with GCC 3.4.0, binding an rvalue to a const reference requires 7504e43c760Sespiean accessible copy constructor. This might be surprising at first sight, 7514e43c760Sespieespecially since most popular compilers do not correctly implement this 7524e43c760Sespierule.</p> 7534e43c760Sespie 7544e43c760Sespie<p>The C++ Standard says that a temporary object should be created in 7554e43c760Sespiethis context and its contents filled with a copy of the object we are 7564e43c760Sespietrying to bind to the reference; it also says that the temporary copy 7574e43c760Sespiecan be elided, but the semantic constraints (eg. accessibility) of the 7584e43c760Sespiecopy constructor still have to be checked.</p> 7594e43c760Sespie 7604e43c760Sespie<p>For further information, you can consult the following paragraphs of 7614e43c760Sespiethe C++ standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and 7624e43c760Sespie[class.temporary]/2.</p></dd> 763c87b03e5Sespie</dl> 764c87b03e5Sespie 7654e43c760Sespie<h3><a name="upgrading">Common problems when upgrading the compiler</a></h3> 766c87b03e5Sespie 7674e43c760Sespie<h4>ABI changes</h4> 768c87b03e5Sespie 7694e43c760Sespie<p>The C++ application binary interface (ABI) consists of two 7704e43c760Sespiecomponents: the first defines how the elements of classes are laid 7714e43c760Sespieout, how functions are called, how function names are mangled, etc; 7724e43c760Sespiethe second part deals with the internals of the objects in libstdc++. 7734e43c760SespieAlthough we strive for a non-changing ABI, so far we have had to 7744e43c760Sespiemodify it with each major release. If you change your compiler to a 7754e43c760Sespiedifferent major release <em>you must recompile all libraries that 7764e43c760Sespiecontain C++ code</em>. If you fail to do so you risk getting linker 7774e43c760Sespieerrors or malfunctioning programs. Some of our Java support libraries 7784e43c760Sespiealso contain C++ code, so you might want to recompile all libraries to 7794e43c760Sespiebe safe. It should not be necessary to recompile if you have changed 7804e43c760Sespieto a bug-fix release of the same version of the compiler; bug-fix 7814e43c760Sespiereleases are careful to avoid ABI changes. See also the 782*a67f0032Smiod<a href="http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html">compatibility 783*a67f0032Smiodsection</a> of the GCC manual.</p> 7844e43c760Sespie 7854e43c760Sespie<p>Remark: A major release is designated by a change to the first or second 7864e43c760Sespiecomponent of the two- or three-part version number. A minor (bug-fix) 7874e43c760Sespierelease is designated by a change to the third component only. Thus GCC 7884e43c760Sespie3.2 and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases 7894e43c760Sespiefor GCC 3.3. With the 3.4 series we are introducing a new naming scheme; 7904e43c760Sespiethe first release of this series is 3.4.0 instead of just 3.4.</p> 7914e43c760Sespie 7924e43c760Sespie<h4>Standard conformance</h4> 7934e43c760Sespie 7944e43c760Sespie<p>With each release, we try to make G++ conform closer to the ISO C++ standard 795c87b03e5Sespie(available at 7964e43c760Sespie<a href="http://www.ncits.org/cplusplus.htm">http://www.ncits.org/cplusplus.htm</a>). 7974e43c760SespieWe have also implemented some of the core and library defect reports 7984e43c760Sespie(available at 7994e43c760Sespie<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> 800c87b03e5Sespie& 8014e43c760Sespie<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> 802c87b03e5Sespierespectively).</p> 803c87b03e5Sespie 8044e43c760Sespie<p>Non-conforming legacy code that worked with older versions of GCC may be 8054e43c760Sespierejected by more recent compilers. There is no command-line switch to ensure 8064e43c760Sespiecompatibility in general, because trying to parse standard-conforming and 8074e43c760Sespieold-style code at the same time would render the C++ frontend unmaintainable. 8084e43c760SespieHowever, some non-conforming constructs are allowed when the command-line 8094e43c760Sespieoption <code>-fpermissive</code> is used.</p> 8104e43c760Sespie 8114e43c760Sespie<p>Two milestones in standard conformance are GCC 3.0 (including a major 8124e43c760Sespieoverhaul of the standard library) and the 3.4.0 version (with its new C++ 8134e43c760Sespieparser).</p> 8144e43c760Sespie 8154e43c760Sespie<h4>New in GCC 3.0</h4> 8164e43c760Sespie 817c87b03e5Sespie<ul> 818c87b03e5Sespie 819c87b03e5Sespie<li>The standard library is much more conformant, and uses the 8204e43c760Sespie<code>std::</code> namespace (which is now a real namespace, not an 8214e43c760Sespiealias for <code>::</code>).</li> 822c87b03e5Sespie 823c87b03e5Sespie<li>The standard header files for the c library don't end with 824c87b03e5Sespie<code>.h</code>, but begin with <code>c</code> (i.e. 825c87b03e5Sespie<code><cstdlib></code> rather than <code><stdlib.h></code>). 826c87b03e5SespieThe <code>.h</code> names are still available, but are deprecated.</li> 827c87b03e5Sespie 828c87b03e5Sespie<li><code><strstream></code> is deprecated, use 829c87b03e5Sespie<code><sstream></code> instead.</li> 830c87b03e5Sespie 831c87b03e5Sespie<li><code>streambuf::seekoff</code> & 832c87b03e5Sespie<code>streambuf::seekpos</code> are private, instead use 833c87b03e5Sespie<code>streambuf::pubseekoff</code> & 834c87b03e5Sespie<code>streambuf::pubseekpos</code> respectively.</li> 835c87b03e5Sespie 836c87b03e5Sespie<li>If <code>std::operator << (std::ostream &, long long)</code> 837c87b03e5Sespiedoesn't exist, you need to recompile libstdc++ with 838c87b03e5Sespie<code>--enable-long-long</code>.</li> 839c87b03e5Sespie 840c87b03e5Sespie</ul> 841c87b03e5Sespie 8424e43c760Sespie<p>If you get lots of errors about things like <code>cout</code> not being 8434e43c760Sespiefound, you've most likely forgotten to tell the compiler to look in the 8444e43c760Sespie<code>std::</code> namespace. There are several ways to do this:</p> 845c87b03e5Sespie 846c87b03e5Sespie<ul> 847c87b03e5Sespie 8484e43c760Sespie<li>Say <code>std::cout</code> at the call. This is the most explicit 849c87b03e5Sespieway of saying what you mean.</li> 850c87b03e5Sespie 8514e43c760Sespie<li>Say <code>using std::cout;</code> somewhere before the call. You 852c87b03e5Sespiewill need to do this for each function or type you wish to use from the 853c87b03e5Sespiestandard library.</li> 854c87b03e5Sespie 8554e43c760Sespie<li>Say <code>using namespace std;</code> somewhere before the call. 856c87b03e5SespieThis is the quick-but-dirty fix. This brings the <em>whole</em> of the 857c87b03e5Sespie<code>std::</code> namespace into scope. <em>Never</em> do this in a 8584e43c760Sespieheader file, as every user of your header file will be affected by this 8594e43c760Sespiedecision.</li> 860c87b03e5Sespie 861c87b03e5Sespie</ul> 862c87b03e5Sespie 8634e43c760Sespie<h4><a name="new34">New in GCC 3.4.0</a></h4> 8644e43c760Sespie 8654e43c760Sespie<p>The new parser brings a lot of improvements, especially concerning 8664e43c760Sespiename-lookup.</p> 8674e43c760Sespie 8684e43c760Sespie<ul> 8694e43c760Sespie 8704e43c760Sespie<li>The "implicit typename" extension got removed (it was already deprecated 8714e43c760Sespiesince GCC 3.1), so that the following code is now rejected, see [14.6]: 8724e43c760Sespie<blockquote><pre> 8734e43c760Sespietemplate <typename> struct A 8744e43c760Sespie{ 8754e43c760Sespie typedef int X; 8764e43c760Sespie}; 8774e43c760Sespie 8784e43c760Sespietemplate <typename T> struct B 8794e43c760Sespie{ 8804e43c760Sespie A<T>::X x; // error 8814e43c760Sespie typename A<T>::X y; // OK 8824e43c760Sespie}; 8834e43c760Sespie 8844e43c760SespieB<void> b; 8854e43c760Sespie</pre></blockquote></li> 8864e43c760Sespie 8874e43c760Sespie<li>For similar reasons, the following code now requires the 8884e43c760Sespie<code>template</code> keyword, see [14.2]: 8894e43c760Sespie<blockquote><pre> 8904e43c760Sespietemplate <typename> struct A 8914e43c760Sespie{ 8924e43c760Sespie template <int> struct X {}; 8934e43c760Sespie}; 8944e43c760Sespie 8954e43c760Sespietemplate <typename T> struct B 8964e43c760Sespie{ 8974e43c760Sespie typename A<T>::X<0> x; // error 8984e43c760Sespie typename A<T>::template X<0> y; // OK 8994e43c760Sespie}; 9004e43c760Sespie 9014e43c760SespieB<void> b; 9024e43c760Sespie</pre></blockquote></li> 9034e43c760Sespie 9044e43c760Sespie<li>We now have two-stage name-lookup, so that the following code is 9054e43c760Sespierejected, see [14.6]/9: 9064e43c760Sespie<blockquote><pre> 9074e43c760Sespietemplate <typename T> int foo() 9084e43c760Sespie{ 9094e43c760Sespie return i; // error 9104e43c760Sespie} 9114e43c760Sespie</pre></blockquote></li> 9124e43c760Sespie 9134e43c760Sespie<li>This also affects members of base classes, see [14.6.2]: 9144e43c760Sespie<blockquote><pre> 9154e43c760Sespietemplate <typename> struct A 9164e43c760Sespie{ 9174e43c760Sespie int i, j; 9184e43c760Sespie}; 9194e43c760Sespie 9204e43c760Sespietemplate <typename T> struct B : A<T> 9214e43c760Sespie{ 9224e43c760Sespie int foo1() { return i; } // error 9234e43c760Sespie int foo2() { return this->i; } // OK 9244e43c760Sespie int foo3() { return B<T>::i; } // OK 9254e43c760Sespie int foo4() { return A<T>::i; } // OK 9264e43c760Sespie 9274e43c760Sespie using A<T>::j; 9284e43c760Sespie int foo5() { return j; } // OK 9294e43c760Sespie}; 9304e43c760Sespie</pre></blockquote></li> 9314e43c760Sespie 9324e43c760Sespie</ul> 933c87b03e5Sespie 934c87b03e5Sespie<p>In addition to the problems listed above, the manual contains a section on 935*a67f0032Smiod<a href="http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html"> 936*a67f0032SmiodCommon Misunderstandings with GNU C++</a>.</p> 937c87b03e5Sespie 938c87b03e5Sespie</body> 939c87b03e5Sespie</html> 940