diff options
Diffstat (limited to 'gcc-4.2.1/bugs.html')
| -rw-r--r-- | gcc-4.2.1/bugs.html | 908 |
1 files changed, 0 insertions, 908 deletions
diff --git a/gcc-4.2.1/bugs.html b/gcc-4.2.1/bugs.html deleted file mode 100644 index 592e2a670..000000000 --- a/gcc-4.2.1/bugs.html +++ /dev/null @@ -1,908 +0,0 @@ -<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> |