diff options
| author | Jing Yu <jingyu@google.com> | 2009-11-05 15:11:04 -0800 |
|---|---|---|
| committer | Jing Yu <jingyu@google.com> | 2009-11-05 15:11:04 -0800 |
| commit | df62c1c110e8532b995b23540b7e3695729c0779 (patch) | |
| tree | dbbd4cbdb50ac38011e058a2533ee4c3168b0205 /gcc-4.2.1/bugs.html | |
| parent | 8d401cf711539af5a2f78d12447341d774892618 (diff) | |
| download | toolchain_gcc-df62c1c110e8532b995b23540b7e3695729c0779.tar.gz toolchain_gcc-df62c1c110e8532b995b23540b7e3695729c0779.tar.bz2 toolchain_gcc-df62c1c110e8532b995b23540b7e3695729c0779.zip | |
Check in gcc sources for prebuilt toolchains in Eclair.
Diffstat (limited to 'gcc-4.2.1/bugs.html')
| -rw-r--r-- | gcc-4.2.1/bugs.html | 908 |
1 files changed, 908 insertions, 0 deletions
diff --git a/gcc-4.2.1/bugs.html b/gcc-4.2.1/bugs.html new file mode 100644 index 000000000..592e2a670 --- /dev/null +++ b/gcc-4.2.1/bugs.html @@ -0,0 +1,908 @@ +<html> + +<head> +<title>GCC Bugs</title> +</head> + +<body> +<h1>GCC Bugs</h1> + +<p>The latest version of this document is always available at +<a href="http://gcc.gnu.org/bugs.html">http://gcc.gnu.org/bugs.html</a>.</p> + +<hr /> + +<h2>Table of Contents</h2> +<ul> +<li><a href="#report">Reporting Bugs</a> + <ul> + <li><a href="#need">What we need</a></li> + <li><a href="#dontwant">What we DON'T want</a></li> + <li><a href="#where">Where to post it</a></li> + <li><a href="#detailed">Detailed bug reporting instructions</a></li> + <li><a href="#gnat">Detailed bug reporting instructions for GNAT</a></li> + <li><a href="#pch">Detailed bug reporting instructions when using a precompiled header</a></li> + </ul> +</li> +<li><a href="#known">Frequently Reported Bugs in GCC</a> + <ul> + <li><a href="#cxx">C++</a> + <ul> + <li><a href="#missing">Missing features</a></li> + <li><a href="#fixed34">Bugs fixed in the 3.4 series</a></li> + </ul> + </li> + <li><a href="#fortran">Fortran</a></li> + </ul> +</li> +<li><a href="#nonbugs">Non-bugs</a> + <ul> + <li><a href="#nonbugs_general">General</a></li> + <li><a href="#nonbugs_c">C</a></li> + <li><a href="#nonbugs_cxx">C++</a> + <ul> + <li><a href="#upgrading">Common problems when upgrading the compiler</a></li> + </ul> + </li> + </ul> +</li> +</ul> + +<hr /> + +<h1><a name="report">Reporting Bugs</a></h1> + +<p>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.</p> + +<p>Before you report a bug, please check the +<a href="#known">list of well-known bugs</a> and, <strong>if possible, +try a current development snapshot</strong>. +If you want to report a bug with versions of GCC before 3.4 we strongly +recommend upgrading to the current release first.</p> + +<p>Before reporting that GCC compiles your code incorrectly, please +compile it with <code>gcc -Wall</code> and see whether this shows +anything wrong with your code that could be the cause instead of a bug +in GCC.</p> + +<h2>Summarized bug reporting instructions</h2> + +<p>After this summary, you'll find detailed bug reporting +instructions, that explain how to obtain some of the information +requested in this summary.</p> + +<h3><a name="need">What we need</a></h3> + +<p>Please include in your bug report all of the following items, the first +three of which can be obtained from the output of <code>gcc -v</code>:</p> + +<ul> + <li>the exact version of GCC;</li> + <li>the system type;</li> + <li>the options given when GCC was configured/built;</li> + <li>the complete command line that triggers the bug;</li> + <li>the compiler output (error messages, warnings, etc.); and</li> + <li>the <em>preprocessed</em> file (<code>*.i*</code>) that triggers the + bug, generated by adding <code>-save-temps</code> 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).</li> +</ul> + +<h3><a name="dontwant">What we do <strong>not</strong> want</a></h3> + +<ul> + <li>A source file that <code>#include</code>s header files that are left + out of the bug report (see above)</li> + + <li>That source file and a collection of header files.</li> + + <li>An attached archive (tar, zip, shar, whatever) containing all + (or some :-) of the above.</li> + + <li>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 <b>apparently</b> triggers the bug, + with some pieces replaced with ellipses or comments for extra + obfuscation :-)</li> + + <li>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? :-)</li> + + <li>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)</li> + + <li>Assembly files (<code>*.s</code>) produced by the compiler, or any + binary files, such as object files, executables, core files, or + precompiled header files</li> + + <li>Duplicate bug reports, or reports of bugs already fixed in the + development tree, especially those that have already been reported + as fixed last week :-)</li> + + <li>Bugs in the assembler, the linker or the C library. These are + separate projects, with separate mailing lists and different bug + reporting procedures</li> + + <li>Bugs in releases or snapshots of GCC not issued by the GNU + Project. Report them to whoever provided you with the release</li> + + <li>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</li> +</ul> + +<h3><a name="where">Where to post it</a></h3> + +<p>Please submit your bug report directly to the +<a href="http://gcc.gnu.org/bugzilla/">GCC bug database</a>. +Alternatively, you can use the <code>gccbug</code> script that mails your bug +report to the bug database. +<br /> +Only if all this is absolutely impossible, mail all information to +<a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a>.</p> + +<h2><a name="detailed">Detailed bug reporting instructions</a></h2> + +<p>Please refer to the <a href="#gnat">next section</a> when reporting +bugs in GNAT, the Ada compiler, or to the <a href="#pch">one after +that</a> when reporting bugs that appear when using a precompiled header.</p> + +<p>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.</p> + +<blockquote><p><code>gcc -v -save-temps <i>all-your-options +source-file</i></code></p></blockquote> + +<p>The <b>only</b> 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.</p> + +<p>Since we're supposed to be able to re-create the assembly output +(extension <code>.s</code>), 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.</p> + +<p>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 <code>INCLUDE</code> directives in Fortran code, +which are not processed by the preprocessor, but the compiler. In that case, +we need the main file and all <code>INCLUDE</code>d 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.</p> + +<h2><a name="gnat">Detailed bug reporting instructions for GNAT</a></h2> + +<p>See the <a href="#detailed">previous section</a> for bug reporting +instructions for GCC language implementations other than Ada.</p> + +<p>Bug reports have to contain at least the following information in +order to be useful:</p> + +<ul> +<li>the exact version of GCC, as shown by "<code>gcc -v</code>";</li> +<li>the system type;</li> +<li>the options when GCC was configured/built;</li> +<li>the exact command line passed to the <code>gcc</code> program +triggering the bug +(not just the flags passed to <code>gnatmake</code>, but +<code>gnatmake</code> prints the parameters it passed to <code>gcc</code>)</li> +<li>a collection of source files for reproducing the bug, +preferably a minimal set (see below);</li> +<li>a description of the expected behavior;</li> +<li>a description of actual behavior.</li> +</ul> + +<p>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 <code>gnatchop</code>, +i.e. contains no non-Ada text. If the compilation terminated +normally, you can usually obtain a list of dependencies using the +"<code>gnatls -d <i>main_unit</i></code>" command, where +<code><i>main_unit</i></code> is the file name of the main compilation +unit (which is also passed to <code>gcc</code>).</p> + +<p>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.</p> + +<p>If you use <code>gnatprep</code>, be sure to send in preprocessed +sources (unless you have to report a bug in <code>gnatprep</code>).</p> + +<p>When you have checked that your report meets these criteria, please +submit it according to our <a href="#where">generic instructions</a>. +(If you use a mailing list for reporting, please include an +"<code>[Ada]</code>" tag in the subject.)</p> + +<h2><a name="pch">Detailed bug reporting instructions when using a +precompiled header</a></h2> + +<p>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 <a href="#detailed">above</a>.</p> + +<p>If you've found a bug while <i>building</i> a precompiled header +(for instance, the compiler crashes), follow the usual instructions +<a href="#detailed">above</a>.</p> + +<p>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 <code>.i</code> 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.</p> + +<p>Please <strong>don't</strong> send us the actual precompiled +header. It is likely to be very large and we can't use it to +reproduce the problem.</p> + +<hr /> + +<h1><a name="known">Frequently Reported Bugs in GCC</a></h1> + +<p>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.</p> + +<p>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: +<em>fix the code</em>.</p> + +<hr /> + +<h2><a name="cxx">C++</a></h2> + +<h3><a name="missing">Missing features</a></h3> + +<dl> + +<dt>The <code>export</code> keyword is not implemented.</dt> +<dd><p>Most C++ compilers (G++ included) do not yet implement +<code>export</code>, which is necessary for separate compilation of +template declarations and definitions. Without <code>export</code>, 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.</p></dd> + +</dl> + +<h3><a name="fixed34">Bugs fixed in the 3.4 series</a></h3> + +<p>The following bugs are present up to (and including) GCC 3.3.x. +They have been fixed in 3.4.0.</p> + +<dl> + +<dt>Two-stage name-lookup.</dt> + +<dd><p>GCC did not implement two-stage name-lookup (also see +<a href="#new34">below</a>).</p></dd> + +<dt>Covariant return types.</dt> + +<dd><p>GCC did not implement non-trivial covariant returns.</p></dd> + +<dt>Parse errors for "simple" code.</dt> + +<dd><p>GCC gave parse errors for seemingly simple code, such as</p> + +<blockquote><pre> +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 +} +</pre></blockquote> + +<p>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.</p> + +<p>The problem in the first case was that GCC started to parse the +declaration of <code>b</code> as a function called <code>b</code> returning +<code>B</code>, taking a function returning <code>A</code> as an argument. +When it encountered the <code>1</code>, 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:</p> + +<blockquote><pre> +B b((0,A()),A(1)); +</pre></blockquote> + +<p>The work-around for simpler cases like the second one was to add +additional parentheses around the expressions that were mistaken as +declarations:</p> + +<blockquote><pre> +(B(A(2))).foo(); +</pre></blockquote> + +<p>In the third case, however, additional parentheses were causing +the problems: The compiler interpreted <code>A()</code> as a function +(taking no arguments, returning <code>A</code>), and <code>(A())</code> +as a cast lacking an expression to be casted, hence the parse error. +The work-around was to omit the parentheses:</p> + +<blockquote><pre> +return A(); +</pre></blockquote> + +<p>This problem occurred in a number of variants; in <code>throw</code> +statements, people also frequently put the object in parentheses.</p></dd> + +</dl> + +<hr /> + +<h2><a name="fortran">Fortran</a></h2> + +<p>G77 bugs are documented in the G77 manual rather than +explicitly listed here. Please see +<a href="http://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Trouble.html">Known Causes of +Trouble with GNU Fortran</a> in the G77 manual.</p> + +<hr /> + +<h1><a name="nonbugs">Non-bugs</a></h1> + +<p>The following are not actually bugs, but are reported often +enough to warrant a mention here.</p> + +<p>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.</p> + +<hr /> + +<h2><a name="nonbugs_general">General</a></h2> + +<dl> +<dt>Problems with floating point numbers - the +<a href="http://gcc.gnu.org/PR323">most often reported non-bug</a>.</dt> +<dd><p>In a number of cases, GCC appears to perform floating point +computations incorrectly. For example, the C++ program</p> +<blockquote><pre> +#include <iostream> + +int main() +{ + double a = 0.5; + double b = 0.01; + std::cout << (int)(a / b) << std::endl; + return 0; +} +</pre></blockquote> +<p>might print 50 on some systems and optimization levels, and 49 on +others.</p> + +<p>This is the result of <em>rounding</em>: 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.</p> + +<p>This is not a bug in the compiler, but an inherent limitation of +the floating point types. Please study +<a href="http://www.validlab.com/goldberg/paper.ps">this paper</a> +for more information.</p></dd> +</dl> + +<hr /> + +<h2><a name="nonbugs_c">C</a></h2> + +<dl> +<dt>Increment/decrement operator (<code>++</code>/<code>--</code>) not +working as expected - a <a href="http://gcc.gnu.org/PR11751">problem with +many variations</a>.</dt> + +<dd><p>The following expressions have unpredictable results:</p> +<blockquote><pre> +x[i]=++i +foo(i,++i) +i*(++i) /* special case with foo=="operator*" */ +std::cout << i << ++i /* foo(foo(std::cout,i),++i) */ +</pre></blockquote> +<p>since the <code>i</code> without increment can be evaluated before or +after <code>++i</code>.</p> + +<p>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.</p> + +<p>Modifying a value twice between two sequence points as shown in the +following examples is even worse:</p> +<blockquote><pre> +i=++i +foo(++i,++i) +(++i)*(++i) /* special case with foo=="operator*" */ +std::cout << ++i << ++i /* foo(foo(std::cout,++i),++i) */ +</pre></blockquote> +<p>This leads to undefined behavior (i.e. the compiler can do +anything).</p></dd> + + +<dt>Casting does not work as expected when optimization is turned on.</dt> + +<dd><p>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 <code>short</code>s and 32-bit +<code>int</code>s):</p> +<blockquote><pre> +#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; +} +</pre></blockquote> +<p>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.</p> + +<p>In the case above, the compiler may assume that no access through an +integer pointer can change the array <code>a</code>, consisting of shorts. +Thus, <code>printf</code> may be called with the original values of +<code>a[0]</code> and <code>a[1]</code>. What really happens is up to +the compiler and may change with architecture and optimization level.</p> + +<p>Recent versions of GCC turn on the option <code>-fstrict-aliasing</code> +(which allows alias-based optimizations) by default with <code>-O2</code>. +And some architectures then really print "1111 1111" as result. Without +optimization the executable will generate the "expected" output +"2222 2222".</p> + +<p>To disable optimizations based on alias-analysis for faulty legacy code, +the option <code>-fno-strict-aliasing</code> can be used as a work-around.</p> + +<p>The option <code>-Wstrict-aliasing</code> (which is included in +<code>-Wall</code>) warns about some - but not all - cases of violation +of aliasing rules when <code>-fstrict-aliasing</code> is active.</p> + +<p>To fix the code above, you can use a <code>union</code> instead of a +cast (note that this is a GCC extension which might not work with other +compilers):</p> +<blockquote><pre> +#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; +} +</pre></blockquote> +<p>Now the result will always be "2222 2222".</p> + +<p>For some more insight into the subject, please have a look at +<a href="http://mail-index.NetBSD.org/tech-kern/2003/08/11/0001.html">this +article</a>.</p></dd> + + +<dt>Cannot use preprocessor directive in macro arguments.</dt> +<dd><p>Let me guess... you used an older version of GCC to compile code +that looks something like this:</p> +<blockquote><pre> + memcpy(dest, src, +#ifdef PLATFORM1 + 12 +#else + 24 +#endif + ); +</pre></blockquote> +<p>and you got a whole pile of error messages:</p> +<blockquote><pre> +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 +</pre></blockquote> + +<p>This is because your C library's <code><string.h></code> happens +to define <code>memcpy</code> as a macro - which is perfectly legitimate. +In recent versions of glibc, for example, <code>printf</code> is among those +functions which are implemented as macros.</p> + +<p>Versions of GCC prior to 3.3 did not allow you to put <code>#ifdef</code> +(or any other preprocessor directive) inside the arguments of a macro. The +code therefore would not compile.</p> + +<p>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.</p> + +<p>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</p> +<blockquote><pre> +#ifdef PLATFORM1 + memcpy(dest, src, 12); +#else + memcpy(dest, src, 24); +#endif +</pre></blockquote> +<p>This is a bit more typing, but I personally think it's better style +in addition to being more portable.</p></dd> + + +<dt>Cannot initialize a static variable with <code>stdin</code>.</dt> +<dd><p>This has nothing to do with GCC, but people ask us about it a +lot. Code like this:</p> + +<blockquote><pre> +#include <stdio.h> + +FILE *yyin = stdin; +</pre></blockquote> + +<p>will not compile with GNU libc, because <code>stdin</code> is not a +constant. This was done deliberately, to make it easier to maintain +binary compatibility when the type <code>FILE</code> needs to be changed. +It is surprising for people used to traditional Unix C libraries, but it +is permitted by the C standard.</p> + +<p>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.</p> + +<p>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 +<a href="http://www.gnu.org/software/libc/">GNU libc web pages</a> +for details. +</p></dd> +</dl> + +<hr /> + +<h2><a name="nonbugs_cxx">C++</a></h2> + +<dl> +<dt>Nested classes can access private members and types of the containing +class.</dt> + +<dd><p>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.</p></dd> + +<dt>G++ emits two copies of constructors and destructors.</dt> + +<dd><p>In general there are <em>three</em> types of constructors (and +destructors).</p> +<ol> +<li>The complete object constructor/destructor.</li> +<li>The base object constructor/destructor.</li> +<li>The allocating constructor/deallocating destructor.</li> +</ol> +<p>The first two are different, when virtual base classes are involved. +</p></dd> + +<dt>Global destructors are not run in the correct order.</dt> + +<dd><p>Global destructors should be run in the reverse order of their +constructors <em>completing</em>. In most cases this is the same as +the reverse order of constructors <em>starting</em>, but sometimes it +is different, and that is important. You need to compile and link your +programs with <code>--use-cxa-atexit</code>. We have not turned this +switch on by default, as it requires a <code>cxa</code> aware runtime +library (<code>libc</code>, <code>glibc</code>, or equivalent).</p></dd> + +<dt>Classes in exception specifiers must be complete types.</dt> + +<dd><p>[15.4]/1 tells you that you cannot have an incomplete type, or +pointer to incomplete (other than <code><i>cv</i> void *</code>) in +an exception specification.</p></dd> + +<dt>Exceptions don't work in multithreaded applications.</dt> + +<dd><p>You need to rebuild g++ and libstdc++ with +<code>--enable-threads</code>. 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.</p></dd> + +<dt>Templates, scoping, and digraphs.</dt> + +<dd><p>If you have a class in the global namespace, say named <code>X</code>, +and want to give it as a template argument to some other class, say +<code>std::vector</code>, then <code>std::vector<::X></code> +fails with a parser error.</p> + +<p>The reason is that the standard mandates that the sequence +<code><:</code> is treated as if it were the token <code>[</code>. +(There are several such combinations of characters - they are called +<em>digraphs</em>.) Depending on the version, the compiler then reports +a parse error before the character <code>:</code> (the colon before +<code>X</code>) or a missing closing bracket <code>]</code>.</p> + +<p>The simplest way to avoid this is to write <code>std::vector< +::X></code>, i.e. place a space between the opening angle bracket +and the scope operator.</p></dd> + + +<dt><a name="cxx_rvalbind">Copy constructor access check while +initializing a reference.</a></dt> + +<dd><p>Consider this code:</p> + +<blockquote><pre> +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 +}</pre></blockquote> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p></dd> +</dl> + +<h3><a name="upgrading">Common problems when upgrading the compiler</a></h3> + +<h4>ABI changes</h4> + +<p>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 <em>you must recompile all libraries that +contain C++ code</em>. 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 +<a href="http://gcc.gnu.org/onlinedocs/gcc/Compatibility.html">compatibility +section</a> of the GCC manual.</p> + +<p>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.</p> + +<h4>Standard conformance</h4> + +<p>With each release, we try to make G++ conform closer to the ISO C++ standard +(available at +<a href="http://www.ncits.org/cplusplus.htm">http://www.ncits.org/cplusplus.htm</a>). +We have also implemented some of the core and library defect reports +(available at +<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> +& +<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> +respectively).</p> + +<p>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 <code>-fpermissive</code> is used.</p> + +<p>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).</p> + +<h4>New in GCC 3.0</h4> + +<ul> + +<li>The standard library is much more conformant, and uses the +<code>std::</code> namespace (which is now a real namespace, not an +alias for <code>::</code>).</li> + +<li>The standard header files for the c library don't end with +<code>.h</code>, but begin with <code>c</code> (i.e. +<code><cstdlib></code> rather than <code><stdlib.h></code>). +The <code>.h</code> names are still available, but are deprecated.</li> + +<li><code><strstream></code> is deprecated, use +<code><sstream></code> instead.</li> + +<li><code>streambuf::seekoff</code> & +<code>streambuf::seekpos</code> are private, instead use +<code>streambuf::pubseekoff</code> & +<code>streambuf::pubseekpos</code> respectively.</li> + +<li>If <code>std::operator << (std::ostream &, long long)</code> +doesn't exist, you need to recompile libstdc++ with +<code>--enable-long-long</code>.</li> + +</ul> + +<p>If you get lots of errors about things like <code>cout</code> not being +found, you've most likely forgotten to tell the compiler to look in the +<code>std::</code> namespace. There are several ways to do this:</p> + +<ul> + +<li>Say <code>std::cout</code> at the call. This is the most explicit +way of saying what you mean.</li> + +<li>Say <code>using std::cout;</code> somewhere before the call. You +will need to do this for each function or type you wish to use from the +standard library.</li> + +<li>Say <code>using namespace std;</code> somewhere before the call. +This is the quick-but-dirty fix. This brings the <em>whole</em> of the +<code>std::</code> namespace into scope. <em>Never</em> do this in a +header file, as every user of your header file will be affected by this +decision.</li> + +</ul> + +<h4><a name="new34">New in GCC 3.4.0</a></h4> + +<p>The new parser brings a lot of improvements, especially concerning +name-lookup.</p> + +<ul> + +<li>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]: +<blockquote><pre> +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; +</pre></blockquote></li> + +<li>For similar reasons, the following code now requires the +<code>template</code> keyword, see [14.2]: +<blockquote><pre> +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; +</pre></blockquote></li> + +<li>We now have two-stage name-lookup, so that the following code is +rejected, see [14.6]/9: +<blockquote><pre> +template <typename T> int foo() +{ + return i; // error +} +</pre></blockquote></li> + +<li>This also affects members of base classes, see [14.6.2]: +<blockquote><pre> +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 +}; +</pre></blockquote></li> + +</ul> + +<p>In addition to the problems listed above, the manual contains a section on +<a href="http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Misunderstandings.html"> +Common Misunderstandings with GNU C++</a>.</p> + +</body> +</html> |