| |
| GCC Bugs |
| |
| The latest version of this document is always available at |
| [1]http://gcc.gnu.org/bugs.html. |
| _________________________________________________________________ |
| |
| Table of Contents |
| |
| * [2]Reporting Bugs |
| + [3]What we need |
| + [4]What we DON'T want |
| + [5]Where to post it |
| + [6]Detailed bug reporting instructions |
| + [7]Detailed bug reporting instructions for GNAT |
| + [8]Detailed bug reporting instructions when using a precompiled |
| header |
| * [9]Frequently Reported Bugs in GCC |
| + [10]C++ |
| o [11]Missing features |
| o [12]Bugs fixed in the 3.4 series |
| + [13]Fortran |
| * [14]Non-bugs |
| + [15]General |
| + [16]C |
| + [17]C++ |
| o [18]Common problems when upgrading the compiler |
| _________________________________________________________________ |
| |
| Reporting Bugs |
| |
| The main purpose of a bug report is to enable us to fix the bug. The most |
| important prerequisite for this is that the report must be complete and |
| self-contained. |
| |
| Before you report a bug, please check the [19]list of well-known bugs and, |
| if possible, try a current development snapshot. If you want to report a bug |
| with versions of GCC before 3.4 we strongly recommend upgrading to the |
| current release first. |
| |
| Before reporting that GCC compiles your code incorrectly, please compile it |
| with gcc -Wall and see whether this shows anything wrong with your code that |
| could be the cause instead of a bug in GCC. |
| |
| Summarized bug reporting instructions |
| |
| After this summary, you'll find detailed bug reporting instructions, that |
| explain how to obtain some of the information requested in this summary. |
| |
| What we need |
| |
| Please include in your bug report all of the following items, the first |
| three of which can be obtained from the output of gcc -v: |
| * the exact version of GCC; |
| * the system type; |
| * the options given when GCC was configured/built; |
| * the complete command line that triggers the bug; |
| * the compiler output (error messages, warnings, etc.); and |
| * the preprocessed file (*.i*) that triggers the bug, generated by adding |
| -save-temps to the complete compilation command, or, in the case of a |
| bug report for the GNAT front end, a complete set of source files (see |
| below). |
| |
| What we do not want |
| |
| * A source file that #includes header files that are left out of the bug |
| report (see above) |
| * That source file and a collection of header files. |
| * An attached archive (tar, zip, shar, whatever) containing all (or some |
| :-) of the above. |
| * A code snippet that won't cause the compiler to produce the exact output |
| mentioned in the bug report (e.g., a snippet with just a few lines |
| around the one that apparently triggers the bug, with some pieces |
| replaced with ellipses or comments for extra obfuscation :-) |
| * The location (URL) of the package that failed to build (we won't |
| download it, anyway, since you've already given us what we need to |
| duplicate the bug, haven't you? :-) |
| * An error that occurs only some of the times a certain file is compiled, |
| such that retrying a sufficient number of times results in a successful |
| compilation; this is a symptom of a hardware problem, not of a compiler |
| bug (sorry) |
| * Assembly files (*.s) produced by the compiler, or any binary files, such |
| as object files, executables, core files, or precompiled header files |
| * Duplicate bug reports, or reports of bugs already fixed in the |
| development tree, especially those that have already been reported as |
| fixed last week :-) |
| * Bugs in the assembler, the linker or the C library. These are separate |
| projects, with separate mailing lists and different bug reporting |
| procedures |
| * Bugs in releases or snapshots of GCC not issued by the GNU Project. |
| Report them to whoever provided you with the release |
| * Questions about the correctness or the expected behavior of certain |
| constructs that are not GCC extensions. Ask them in forums dedicated to |
| the discussion of the programming language |
| |
| Where to post it |
| |
| Please submit your bug report directly to the [20]GCC bug database. |
| Alternatively, you can use the gccbug script that mails your bug report to |
| the bug database. |
| Only if all this is absolutely impossible, mail all information to |
| [21]gcc-bugs@gcc.gnu.org. |
| |
| Detailed bug reporting instructions |
| |
| Please refer to the [22]next section when reporting bugs in GNAT, the Ada |
| compiler, or to the [23]one after that when reporting bugs that appear when |
| using a precompiled header. |
| |
| In general, all the information we need can be obtained by collecting the |
| command line below, as well as its output and the preprocessed file it |
| generates. |
| |
| gcc -v -save-temps all-your-options source-file |
| |
| The only excuses to not send us the preprocessed sources are (i) if you've |
| found a bug in the preprocessor, (ii) if you've reduced the testcase to a |
| small file that doesn't include any other file or (iii) if the bug appears |
| only when using precompiled headers. If you can't post the preprocessed |
| sources because they're proprietary code, then try to create a small file |
| that triggers the same problem. |
| |
| Since we're supposed to be able to re-create the assembly output (extension |
| .s), you usually should not include it in the bug report, although you may |
| want to post parts of it to point out assembly code you consider to be |
| wrong. |
| |
| Please avoid posting an archive (.tar, .shar or .zip); we generally need |
| just a single file to reproduce the bug (the .i/.ii/.f preprocessed file), |
| and, by storing it in an archive, you're just making our volunteers' jobs |
| harder. Only when your bug report requires multiple source files to be |
| reproduced should you use an archive. This is, for example, the case if you |
| are using INCLUDE directives in Fortran code, which are not processed by the |
| preprocessor, but the compiler. In that case, we need the main file and all |
| INCLUDEd files. In any case, make sure the compiler version, error message, |
| etc, are included in the body of your bug report as plain text, even if |
| needlessly duplicated as part of an archive. |
| |
| Detailed bug reporting instructions for GNAT |
| |
| See the [24]previous section for bug reporting instructions for GCC language |
| implementations other than Ada. |
| |
| Bug reports have to contain at least the following information in order to |
| be useful: |
| * the exact version of GCC, as shown by "gcc -v"; |
| * the system type; |
| * the options when GCC was configured/built; |
| * the exact command line passed to the gcc program triggering the bug (not |
| just the flags passed to gnatmake, but gnatmake prints the parameters it |
| passed to gcc) |
| * a collection of source files for reproducing the bug, preferably a |
| minimal set (see below); |
| * a description of the expected behavior; |
| * a description of actual behavior. |
| |
| If your code depends on additional source files (usually package |
| specifications), submit the source code for these compilation units in a |
| single file that is acceptable input to gnatchop, i.e. contains no non-Ada |
| text. If the compilation terminated normally, you can usually obtain a list |
| of dependencies using the "gnatls -d main_unit" command, where main_unit is |
| the file name of the main compilation unit (which is also passed to gcc). |
| |
| If you report a bug which causes the compiler to print a bug box, include |
| that bug box in your report, and do not forget to send all the source files |
| listed after the bug box along with your report. |
| |
| If you use gnatprep, be sure to send in preprocessed sources (unless you |
| have to report a bug in gnatprep). |
| |
| When you have checked that your report meets these criteria, please submit |
| it according to our [25]generic instructions. (If you use a mailing list for |
| reporting, please include an "[Ada]" tag in the subject.) |
| |
| Detailed bug reporting instructions when using a precompiled header |
| |
| If you're encountering a bug when using a precompiled header, the first |
| thing to do is to delete the precompiled header, and try running the same |
| GCC command again. If the bug happens again, the bug doesn't really involve |
| precompiled headers, please report it without using them by following the |
| instructions [26]above. |
| |
| If you've found a bug while building a precompiled header (for instance, the |
| compiler crashes), follow the usual instructions [27]above. |
| |
| If you've found a real precompiled header bug, what we'll need to reproduce |
| it is the sources to build the precompiled header (as a single .i file), the |
| source file that uses the precompiled header, any other headers that source |
| file includes, and the command lines that you used to build the precompiled |
| header and to use it. |
| |
| Please don't send us the actual precompiled header. It is likely to be very |
| large and we can't use it to reproduce the problem. |
| _________________________________________________________________ |
| |
| Frequently Reported Bugs in GCC |
| |
| This is a list of bugs in GCC that are reported very often, but not yet |
| fixed. While it is certainly better to fix bugs instead of documenting them, |
| this document might save people the effort of writing a bug report when the |
| bug is already well-known. |
| |
| There are many reasons why a reported bug doesn't get fixed. It might be |
| difficult to fix, or fixing it might break compatibility. Often, reports get |
| a low priority when there is a simple work-around. In particular, bugs |
| caused by invalid code have a simple work-around: fix the code. |
| _________________________________________________________________ |
| |
| C++ |
| |
| Missing features |
| |
| The export keyword is not implemented. |
| Most C++ compilers (G++ included) do not yet implement export, which |
| is necessary for separate compilation of template declarations and |
| definitions. Without export, a template definition must be in scope |
| to be used. The obvious workaround is simply to place all definitions |
| in the header itself. Alternatively, the compilation unit containing |
| template definitions may be included from the header. |
| |
| Bugs fixed in the 3.4 series |
| |
| The following bugs are present up to (and including) GCC 3.3.x. They have |
| been fixed in 3.4.0. |
| |
| Two-stage name-lookup. |
| GCC did not implement two-stage name-lookup (also see [28]below). |
| |
| Covariant return types. |
| GCC did not implement non-trivial covariant returns. |
| |
| Parse errors for "simple" code. |
| GCC gave parse errors for seemingly simple code, such as |
| |
| struct A |
| { |
| A(); |
| A(int); |
| }; |
| |
| struct B |
| { |
| B(A); |
| B(A,A); |
| void foo(); |
| }; |
| |
| A bar() |
| { |
| B b(A(),A(1)); // Variable b, initialized with two temporaries |
| B(A(2)).foo(); // B temporary, initialized with A temporary |
| return (A()); // return A temporary |
| } |
| |
| Although being valid code, each of the three lines with a comment was |
| rejected by GCC. The work-arounds for older compiler versions |
| proposed below do not change the semantics of the programs at all. |
| |
| The problem in the first case was that GCC started to parse the |
| declaration of b as a function called b returning B, taking a |
| function returning A as an argument. When it encountered the 1, it |
| was too late. To show the compiler that this should be really an |
| expression, a comma operator with a dummy argument could be used: |
| |
| B b((0,A()),A(1)); |
| |
| The work-around for simpler cases like the second one was to add |
| additional parentheses around the expressions that were mistaken as |
| declarations: |
| |
| (B(A(2))).foo(); |
| |
| In the third case, however, additional parentheses were causing the |
| problems: The compiler interpreted A() as a function (taking no |
| arguments, returning A), and (A()) as a cast lacking an expression to |
| be casted, hence the parse error. The work-around was to omit the |
| parentheses: |
| |
| return A(); |
| |
| This problem occurred in a number of variants; in throw statements, |
| people also frequently put the object in parentheses. |
| _________________________________________________________________ |
| |
| Fortran |
| |
| G77 bugs are documented in the G77 manual rather than explicitly listed |
| here. Please see [29]Known Causes of Trouble with GNU Fortran in the G77 |
| manual. |
| _________________________________________________________________ |
| |
| Non-bugs |
| |
| The following are not actually bugs, but are reported often enough to |
| warrant a mention here. |
| |
| It is not always a bug in the compiler, if code which "worked" in a previous |
| version, is now rejected. Earlier versions of GCC sometimes were less picky |
| about standard conformance and accepted invalid source code. In addition, |
| programming languages themselves change, rendering code invalid that used to |
| be conforming (this holds especially for C++). In either case, you should |
| update your code to match recent language standards. |
| _________________________________________________________________ |
| |
| General |
| |
| Problems with floating point numbers - the [30]most often reported non-bug. |
| In a number of cases, GCC appears to perform floating point |
| computations incorrectly. For example, the C++ program |
| |
| #include <iostream> |
| |
| int main() |
| { |
| double a = 0.5; |
| double b = 0.01; |
| std::cout << (int)(a / b) << std::endl; |
| return 0; |
| } |
| |
| might print 50 on some systems and optimization levels, and 49 on |
| others. |
| |
| This is the result of rounding: The computer cannot represent all |
| real numbers exactly, so it has to use approximations. When computing |
| with approximation, the computer needs to round to the nearest |
| representable number. |
| |
| This is not a bug in the compiler, but an inherent limitation of the |
| floating point types. Please study [31]this paper for more |
| information. |
| _________________________________________________________________ |
| |
| C |
| |
| Increment/decrement operator (++/--) not working as expected - a [32]problem |
| with many variations. |
| The following expressions have unpredictable results: |
| |
| x[i]=++i |
| foo(i,++i) |
| i*(++i) /* special case with foo=="operator*" */ |
| std::cout << i << ++i /* foo(foo(std::cout,i),++i) */ |
| |
| since the i without increment can be evaluated before or after ++i. |
| |
| The C and C++ standards have the notion of "sequence points". |
| Everything that happens between two sequence points happens in an |
| unspecified order, but it has to happen after the first and before |
| the second sequence point. The end of a statement and a function call |
| are examples for sequence points, whereas assignments and the comma |
| between function arguments are not. |
| |
| Modifying a value twice between two sequence points as shown in the |
| following examples is even worse: |
| |
| i=++i |
| foo(++i,++i) |
| (++i)*(++i) /* special case with foo=="operator*" */ |
| std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */ |
| |
| This leads to undefined behavior (i.e. the compiler can do anything). |
| |
| Casting does not work as expected when optimization is turned on. |
| This is often caused by a violation of aliasing rules, which are part |
| of the ISO C standard. These rules say that a program is invalid if |
| you try to access a variable through a pointer of an incompatible |
| type. This is happening in the following example where a short is |
| accessed through a pointer to integer (the code assumes 16-bit shorts |
| and 32-bit ints): |
| |
| #include <stdio.h> |
| |
| int main() |
| { |
| short a[2]; |
| |
| a[0]=0x1111; |
| a[1]=0x1111; |
| |
| *(int *)a = 0x22222222; /* violation of aliasing rules */ |
| |
| printf("%x %x\n", a[0], a[1]); |
| return 0; |
| } |
| |
| The aliasing rules were designed to allow compilers more aggressive |
| optimization. Basically, a compiler can assume that all changes to |
| variables happen through pointers or references to variables of a |
| type compatible to the accessed variable. Dereferencing a pointer |
| that violates the aliasing rules results in undefined behavior. |
| |
| In the case above, the compiler may assume that no access through an |
| integer pointer can change the array a, consisting of shorts. Thus, |
| printf may be called with the original values of a[0] and a[1]. What |
| really happens is up to the compiler and may change with architecture |
| and optimization level. |
| |
| Recent versions of GCC turn on the option -fstrict-aliasing (which |
| allows alias-based optimizations) by default with -O2. And some |
| architectures then really print "1111 1111" as result. Without |
| optimization the executable will generate the "expected" output "2222 |
| 2222". |
| |
| To disable optimizations based on alias-analysis for faulty legacy |
| code, the option -fno-strict-aliasing can be used as a work-around. |
| |
| The option -Wstrict-aliasing (which is included in -Wall) warns about |
| some - but not all - cases of violation of aliasing rules when |
| -fstrict-aliasing is active. |
| |
| To fix the code above, you can use a union instead of a cast (note |
| that this is a GCC extension which might not work with other |
| compilers): |
| |
| #include <stdio.h> |
| |
| int main() |
| { |
| union |
| { |
| short a[2]; |
| int i; |
| } u; |
| |
| u.a[0]=0x1111; |
| u.a[1]=0x1111; |
| |
| u.i = 0x22222222; |
| |
| printf("%x %x\n", u.a[0], u.a[1]); |
| return 0; |
| } |
| |
| Now the result will always be "2222 2222". |
| |
| For some more insight into the subject, please have a look at |
| [33]this article. |
| |
| Cannot use preprocessor directive in macro arguments. |
| Let me guess... you used an older version of GCC to compile code that |
| looks something like this: |
| |
| memcpy(dest, src, |
| #ifdef PLATFORM1 |
| 12 |
| #else |
| 24 |
| #endif |
| ); |
| |
| and you got a whole pile of error messages: |
| |
| test.c:11: warning: preprocessing directive not recognized within macro arg |
| test.c:11: warning: preprocessing directive not recognized within macro arg |
| test.c:11: warning: preprocessing directive not recognized within macro arg |
| test.c: In function `foo': |
| test.c:6: undefined or invalid # directive |
| test.c:8: undefined or invalid # directive |
| test.c:9: parse error before `24' |
| test.c:10: undefined or invalid # directive |
| |
| This is because your C library's <string.h> happens to define memcpy |
| as a macro - which is perfectly legitimate. In recent versions of |
| glibc, for example, printf is among those functions which are |
| implemented as macros. |
| |
| Versions of GCC prior to 3.3 did not allow you to put #ifdef (or any |
| other preprocessor directive) inside the arguments of a macro. The |
| code therefore would not compile. |
| |
| As of GCC 3.3 this kind of construct is always accepted and the |
| preprocessor will probably do what you expect, but see the manual for |
| detailed semantics. |
| |
| However, this kind of code is not portable. It is "undefined |
| behavior" according to the C standard; that means different compilers |
| may do different things with it. It is always possible to rewrite |
| code which uses conditionals inside macros so that it doesn't. You |
| could write the above example |
| |
| #ifdef PLATFORM1 |
| memcpy(dest, src, 12); |
| #else |
| memcpy(dest, src, 24); |
| #endif |
| |
| This is a bit more typing, but I personally think it's better style |
| in addition to being more portable. |
| |
| Cannot initialize a static variable with stdin. |
| This has nothing to do with GCC, but people ask us about it a lot. |
| Code like this: |
| |
| #include <stdio.h> |
| |
| FILE *yyin = stdin; |
| |
| will not compile with GNU libc, because stdin is not a constant. This |
| was done deliberately, to make it easier to maintain binary |
| compatibility when the type FILE needs to be changed. It is |
| surprising for people used to traditional Unix C libraries, but it is |
| permitted by the C standard. |
| |
| This construct commonly occurs in code generated by old versions of |
| lex or yacc. We suggest you try regenerating the parser with a |
| current version of flex or bison, respectively. In your own code, the |
| appropriate fix is to move the initialization to the beginning of |
| main. |
| |
| There is a common misconception that the GCC developers are |
| responsible for GNU libc. These are in fact two entirely separate |
| projects; please check the [34]GNU libc web pages for details. |
| _________________________________________________________________ |
| |
| C++ |
| |
| Nested classes can access private members and types of the containing class. |
| Defect report 45 clarifies that nested classes are members of the |
| class they are nested in, and so are granted access to private |
| members of that class. |
| |
| G++ emits two copies of constructors and destructors. |
| In general there are three types of constructors (and destructors). |
| |
| 1. The complete object constructor/destructor. |
| 2. The base object constructor/destructor. |
| 3. The allocating constructor/deallocating destructor. |
| |
| The first two are different, when virtual base classes are involved. |
| |
| Global destructors are not run in the correct order. |
| Global destructors should be run in the reverse order of their |
| constructors completing. In most cases this is the same as the |
| reverse order of constructors starting, but sometimes it is |
| different, and that is important. You need to compile and link your |
| programs with --use-cxa-atexit. We have not turned this switch on by |
| default, as it requires a cxa aware runtime library (libc, glibc, or |
| equivalent). |
| |
| Classes in exception specifiers must be complete types. |
| [15.4]/1 tells you that you cannot have an incomplete type, or |
| pointer to incomplete (other than cv void *) in an exception |
| specification. |
| |
| Exceptions don't work in multithreaded applications. |
| You need to rebuild g++ and libstdc++ with --enable-threads. |
| Remember, C++ exceptions are not like hardware interrupts. You cannot |
| throw an exception in one thread and catch it in another. You cannot |
| throw an exception from a signal handler and catch it in the main |
| thread. |
| |
| Templates, scoping, and digraphs. |
| If you have a class in the global namespace, say named X, and want to |
| give it as a template argument to some other class, say std::vector, |
| then std::vector<::X> fails with a parser error. |
| |
| The reason is that the standard mandates that the sequence <: is |
| treated as if it were the token [. (There are several such |
| combinations of characters - they are called digraphs.) Depending on |
| the version, the compiler then reports a parse error before the |
| character : (the colon before X) or a missing closing bracket ]. |
| |
| The simplest way to avoid this is to write std::vector< ::X>, i.e. |
| place a space between the opening angle bracket and the scope |
| operator. |
| |
| Copy constructor access check while initializing a reference. |
| Consider this code: |
| |
| class A |
| { |
| public: |
| A(); |
| |
| private: |
| A(const A&); // private copy ctor |
| }; |
| |
| A makeA(void); |
| void foo(const A&); |
| |
| void bar(void) |
| { |
| foo(A()); // error, copy ctor is not accessible |
| foo(makeA()); // error, copy ctor is not accessible |
| |
| A a1; |
| foo(a1); // OK, a1 is a lvalue |
| } |
| |
| Starting with GCC 3.4.0, binding an rvalue to a const reference |
| requires an accessible copy constructor. This might be surprising at |
| first sight, especially since most popular compilers do not correctly |
| implement this rule. |
| |
| The C++ Standard says that a temporary object should be created in |
| this context and its contents filled with a copy of the object we are |
| trying to bind to the reference; it also says that the temporary copy |
| can be elided, but the semantic constraints (eg. accessibility) of |
| the copy constructor still have to be checked. |
| |
| For further information, you can consult the following paragraphs of |
| the C++ standard: [dcl.init.ref]/5, bullet 2, sub-bullet 1, and |
| [class.temporary]/2. |
| |
| Common problems when upgrading the compiler |
| |
| ABI changes |
| |
| The C++ application binary interface (ABI) consists of two components: the |
| first defines how the elements of classes are laid out, how functions are |
| called, how function names are mangled, etc; the second part deals with the |
| internals of the objects in libstdc++. Although we strive for a non-changing |
| ABI, so far we have had to modify it with each major release. If you change |
| your compiler to a different major release you must recompile all libraries |
| that contain C++ code. If you fail to do so you risk getting linker errors |
| or malfunctioning programs. Some of our Java support libraries also contain |
| C++ code, so you might want to recompile all libraries to be safe. It should |
| not be necessary to recompile if you have changed to a bug-fix release of |
| the same version of the compiler; bug-fix releases are careful to avoid ABI |
| changes. See also the [35]compatibility section of the GCC manual. |
| |
| Remark: A major release is designated by a change to the first or second |
| component of the two- or three-part version number. A minor (bug-fix) |
| release is designated by a change to the third component only. Thus GCC 3.2 |
| and 3.3 are major releases, while 3.3.1 and 3.3.2 are bug-fix releases for |
| GCC 3.3. With the 3.4 series we are introducing a new naming scheme; the |
| first release of this series is 3.4.0 instead of just 3.4. |
| |
| Standard conformance |
| |
| With each release, we try to make G++ conform closer to the ISO C++ standard |
| (available at [36]http://www.ncits.org/cplusplus.htm). We have also |
| implemented some of the core and library defect reports (available at |
| [37]http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html & |
| [38]http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html |
| respectively). |
| |
| Non-conforming legacy code that worked with older versions of GCC may be |
| rejected by more recent compilers. There is no command-line switch to ensure |
| compatibility in general, because trying to parse standard-conforming and |
| old-style code at the same time would render the C++ frontend |
| unmaintainable. However, some non-conforming constructs are allowed when the |
| command-line option -fpermissive is used. |
| |
| Two milestones in standard conformance are GCC 3.0 (including a major |
| overhaul of the standard library) and the 3.4.0 version (with its new C++ |
| parser). |
| |
| New in GCC 3.0 |
| |
| * The standard library is much more conformant, and uses the std:: |
| namespace (which is now a real namespace, not an alias for ::). |
| * The standard header files for the c library don't end with .h, but begin |
| with c (i.e. <cstdlib> rather than <stdlib.h>). The .h names are still |
| available, but are deprecated. |
| * <strstream> is deprecated, use <sstream> instead. |
| * streambuf::seekoff & streambuf::seekpos are private, instead use |
| streambuf::pubseekoff & streambuf::pubseekpos respectively. |
| * If std::operator << (std::ostream &, long long) doesn't exist, you need |
| to recompile libstdc++ with --enable-long-long. |
| |
| If you get lots of errors about things like cout not being found, you've |
| most likely forgotten to tell the compiler to look in the std:: namespace. |
| There are several ways to do this: |
| * Say std::cout at the call. This is the most explicit way of saying what |
| you mean. |
| * Say using std::cout; somewhere before the call. You will need to do this |
| for each function or type you wish to use from the standard library. |
| * Say using namespace std; somewhere before the call. This is the |
| quick-but-dirty fix. This brings the whole of the std:: namespace into |
| scope. Never do this in a header file, as every user of your header file |
| will be affected by this decision. |
| |
| New in GCC 3.4.0 |
| |
| The new parser brings a lot of improvements, especially concerning |
| name-lookup. |
| * The "implicit typename" extension got removed (it was already deprecated |
| since GCC 3.1), so that the following code is now rejected, see [14.6]: |
| |
| template <typename> struct A |
| { |
| typedef int X; |
| }; |
| |
| template <typename T> struct B |
| { |
| A<T>::X x; // error |
| typename A<T>::X y; // OK |
| }; |
| |
| B<void> b; |
| |
| * For similar reasons, the following code now requires the template |
| keyword, see [14.2]: |
| |
| template <typename> struct A |
| { |
| template <int> struct X {}; |
| }; |
| |
| template <typename T> struct B |
| { |
| typename A<T>::X<0> x; // error |
| typename A<T>::template X<0> y; // OK |
| }; |
| |
| B<void> b; |
| |
| * We now have two-stage name-lookup, so that the following code is |
| rejected, see [14.6]/9: |
| |
| template <typename T> int foo() |
| { |
| return i; // error |
| } |
| |
| * This also affects members of base classes, see [14.6.2]: |
| |
| template <typename> struct A |
| { |
| int i, j; |
| }; |
| |
| template <typename T> struct B : A<T> |
| { |
| int foo1() { return i; } // error |
| int foo2() { return this->i; } // OK |
| int foo3() { return B<T>::i; } // OK |
| int foo4() { return A<T>::i; } // OK |
| |
| using A<T>::j; |
| int foo5() { return j; } // OK |
| }; |
| |
| In addition to the problems listed above, the manual contains a section on |
| [39]Common Misunderstandings with GNU C++. |
| |
| References |
| |
| 1. http://gcc.gnu.org/bugs.html |
| 2. http://gcc.gnu.org/bugs.html#report |
| 3. http://gcc.gnu.org/bugs.html#need |
| 4. http://gcc.gnu.org/bugs.html#dontwant |
| 5. http://gcc.gnu.org/bugs.html#where |
| 6. http://gcc.gnu.org/bugs.html#detailed |
| 7. http://gcc.gnu.org/bugs.html#gnat |
| 8. http://gcc.gnu.org/bugs.html#pch |
| 9. http://gcc.gnu.org/bugs.html#known |
| 10. http://gcc.gnu.org/bugs.html#cxx |
| 11. http://gcc.gnu.org/bugs.html#missing |
| 12. http://gcc.gnu.org/bugs.html#fixed34 |
| 13. http://gcc.gnu.org/bugs.html#fortran |
| 14. http://gcc.gnu.org/bugs.html#nonbugs |
| 15. http://gcc.gnu.org/bugs.html#nonbugs_general |
| 16. http://gcc.gnu.org/bugs.html#nonbugs_c |
| 17. http://gcc.gnu.org/bugs.html#nonbugs_cxx |
| 18. http://gcc.gnu.org/bugs.html#upgrading |
| 19. http://gcc.gnu.org/bugs.html#known |
| 20. http://gcc.gnu.org/bugzilla/ |
| 21. mailto:gcc-bugs@gcc.gnu.org |
| 22. http://gcc.gnu.org/bugs.html#gnat |
| 23. http://gcc.gnu.org/bugs.html#pch |
| 24. http://gcc.gnu.org/bugs.html#detailed |
| 25. http://gcc.gnu.org/bugs.html#where |
| 26. http://gcc.gnu.org/bugs.html#detailed |
| 27. http://gcc.gnu.org/bugs.html#detailed |
| 28. http://gcc.gnu.org/bugs.html#new34 |
| 29. http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html |
| 30. http://gcc.gnu.org/PR323 |
| 31. http://www.validlab.com/goldberg/paper.ps |
| 32. http://gcc.gnu.org/PR11751 |
| 33. http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html |
| 34. http://www.gnu.org/software/libc/ |
| 35. http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html |
| 36. http://www.ncits.org/cplusplus.htm |
| 37. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html |
| 38. http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html |
| 39. http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html |