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