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