+++ /dev/null
-<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="#general">General</a></li>
- <li><a href="#fortran">Fortran</a></li>
- <li><a href="#c">C</a></li>
- <li><a href="#cplusplus">C++</a>
- <ul>
- <li><a href="#updating">Common problems updating from G++ 2.95 to
- G++ 3.0</a></li>
- <li><a href="#nonbugs">Non-bugs</a></li>
- <li><a href="#missing">Missing features</a></li>
- <li><a href="#parsing">Parse errors for "simple" code</a></li>
- <li><a href="#-O3">Optimization at <code>-O3</code> takes a
- very long time</a></li>
- </ul>
- </li>
- </ul>
- </li>
-</ul>
-
-<hr />
-
-<h1><a name="report">Reporting Bugs</a></h1>
-
-<p>Our preferred way of receiving bugs is via the
-<a href="gnats.html">GCC GNATS bug reporting system</a>.</p>
-
-<p>Before you report a bug, please check the
-<a href="#known">list of well-known bugs</a> and, <strong>if possible
-in any way, try a current development snapshot</strong>.
-If you want to report a bug with versions of GCC before 3.1 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>
-
-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>:
-
-<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>E-mail messages that complement previous, incomplete bug
- reports. Post a new, self-contained, full bug report instead, if
- possible as a follow-up to the original bug report</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="gnats.html">GCC GNATS bug database</a>.
-Only if this is not possible, mail all information to
-<a href="mailto:bug-gcc@gnu.org">bug-gcc@gnu.org</a> or
-<a href="mailto:gcc-bugs@gcc.gnu.org">gcc-bugs@gcc.gnu.org</a>.</p>
-
-<p>The GCC lists have message size limits (200 kbytes) and bug reports
-over those limits will currently be bounced. If your bug is larger
-than that, please post it using the <a href="gnats.html">GCC GNATS bug
-database</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><code>gcc -v -save-temps <i>all-your-options
-source-file</i></code></blockquote>
-
-<p>Typically the preprocessed file (extension <code>.i</code> for C or
-<code>.ii</code> for C++) will be large, so please compress the
-resulting file with one of the popular compression programs such as
-bzip2, gzip, zip or compress (in
-decreasing order of preference). Use maximum compression
-(<code>-9</code>) if available. Please include the compressed
-preprocessor output in your bug report, even if the source code is
-freely available elsewhere; it makes the job of our volunteer testers
-much easier.</p>
-
-<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>Whether to use MIME attachments or <code>uuencode</code> is up to
-you. In any case, make sure the compiler command line, version and
-error output are in plain text, so that we don't have to decode the
-bug report in order to tell who should take care of it. A meaningful
-subject indicating language and platform also helps.</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 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. 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>
-
-<p>If you fail to supply enough information for a bug report to be
-reproduced, someone will probably ask you to post additional
-information (or just ignore your bug report, if they're in a bad day,
-so try to get it right on the first posting :-). In this case, please
-post the additional information to the bug reporting mailing list, not
-just to the person who requested it, unless explicitly told so. If
-possible, please include in this follow-up all the information you had
-supplied in the incomplete bug report (including the preprocessor
-output), so that the new bug report is self-contained.</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>
-
-<h2><a name="fortran">Fortran</a></h2>
-
-<p>Fortran bugs are documented in the G77 manual rather than
-explicitly listed here. Please see
-<a href="http://gcc.gnu.org/onlinedocs/g77/Trouble.html">Known Causes of
-Trouble with GNU Fortran</a> in the G77 manual.</p>
-
-<hr />
-
-<h2><a name="c">C</a></h2>
-
-<p>The following are not bugs in the C compiler, but are reported
-often enough to warrant a mention here.</p>
-
-<dl>
-<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 (GNU/Linux libc6), 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/glibc/">GNU libc web pages</a>
-for details.
-</p></dd>
-
-<dt>Cannot use preprocessor directive in macro arguments.</dt>
-<dd><p>Let me guess... you wrote 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><code>
-
-test.c:11: warning: preprocessing directive not recognized within
-macro arg<br />
-test.c:11: warning: preprocessing directive not recognized within
-macro arg<br />
-test.c:11: warning: preprocessing directive not recognized within
-macro arg<br />
-test.c: In function `foo':<br />
-test.c:6: undefined or invalid # directive<br />
-test.c:8: undefined or invalid # directive<br />
-test.c:9: parse error before `24'<br />
-test.c:10: undefined or invalid # directive<br />
-test.c:11: parse error before `#'<br />
-</code></blockquote>
-
-<p><strong>Update:</strong> As of GCC 3.2 this kind of construct is
-always accepted and CPP will probably do what you expect, but see the
-manual for detailed semantics.</p>
-
-<p>However, versions of GCC prior to 3.2 did not allow you to put
-<code>#ifdef</code> (or any other directive) inside the arguments of a
-macro. Your C library's <code><string.h></code> happens to
-define <code>memcpy</code> as a macro - this is perfectly legitimate.
-The code therefore would not compile.</p>
-
-<p>This kind of code is not portable. It is "undefined behavior"
-according to the C standard; that means different compilers will 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>
-
-<p>In recent versions of glibc, <code>printf</code> is among the
-functions which are implemented as macros.</p></dd>
-</dl>
-
-<hr />
-
-<h2><a name="cplusplus">C++</a></h2>
-
-<p>This is the list of bugs (and non-bugs) in g++ (aka GNU C++) 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. <a href="#report">How to report bugs</a> tells you how to
-report a bug.</p>
-
-<p>There are many reasons why reported bugs don'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 C++ code have a simple work-around,
-<em>fix the code</em>. Now that there is an agreed ISO/ANSI standard
-for C++, the compiler has a definitive document to adhere to. Earlier
-versions might have accepted source code that is <em>no longer</em>
-C++. This means that code which might have `worked' in a previous
-version, is now rejected. You should update your code to be C++.</p>
-
-<p>You should try to use the latest stable release of the GNU C++
-compiler.</p>
-
-<h3><a name="updating">Common problems updating from G++ 2.95 to G++
-3.0</a></h3>
-
-<p>G++ 3.0 conforms much closer to the ISO C++ standard (available at
-<a href="http://www.ncits.org/cplusplus.htm">http://www.ncits.org/cplusplus.htm</a>).</p>
-
-<p>We have also implemented some of the core and library defect reports
-(available at
-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html">http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a>
-&
-<a href="http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html">
-http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-defects.html</a>
-respectively).</p>
-
-<ul>
-
-<li>The ABI has changed. This means that both class layout and name
-mangling is different. You <em>must</em> recompile all c++ libraries (if
-you don't you will get link errors).</li>
-
-<li>The standard library is much more conformant, and uses the
-<code>std::</code> namespace.</li>
-
-<li><code>std::</code> 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>
-
-This means you may get lots of errors about things like
-<code>strcmp</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,
-
-<ul>
-
-<li>Say, <code>std::strcmp</code> at the call. This is the most explicit
-way of saying what you mean.</li>
-
-<li>Say, <code>using std::strcmp;</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 you will be forcing users of your header file to do the
-same.</li>
-
-</ul>
-
-<h3><a name="abi">ABI bugs</a></h3>
-
-<p>3.0 had a new ABI, which affected class layout, function mangling and
-calling conventions. We had intended it to be complete, unfortunately
-some issues came to light, too late to fix in the 3.0 series.
-The ABI should not change in dot releases, so we addressed most issues
-in GCC 3.1.
-</p>
-
-<dl>
-
-<dt>Covariant return types</dt>
-
-<dd>We do not implement non-trivial covariant returns. We also generate
-incorrect virtual function tables for trivial covariance. Although
-trivial covariance will work, it is incompatible with the ABI. GNATS PR
-3706 tracks this problem.</dd>
-
-</dl>
-
-<h3><a name="nonbugs">Non-bugs</a></h3>
-
-<p>Here are some features that have been reported as bugs, but are
-not.</p>
-
-<dl>
-
-<dt>Nested classes can access private types of the containing
-class.</dt>
-<dd><p>G++ now implements type access control on member types. 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>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>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 destructor/deallocating destructor.</li>
-</ol>
-<p>The first two are different, when virtual base classes are involved.
-In some cases we can do better, and this is logged in GNATS.</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>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>Problems with floating point computations.</dt>
-<dd><p>In a number of cases, GCC appears to perform floating point
-computations incorrectly. For example, the program</p>
-<blockquote><code>
-#include <iostream><br />
-<br />
-int main() {<br />
-<br />
- double min = 0.0;<br />
- double max = 0.5;<br />
- double width = 0.01;<br />
- std::cout << (int)(((max - min) / width) - 1) <<
- std::endl;<br />
-<br />
-}<br />
-</code></blockquote>
-<p>might print 49 on some systems and optimization levels, and 48 on
-others.</p>
-
-<p>The 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 float and double types. Please study
-<a href="http://www.validlab.com/goldberg/paper.ps">this paper</a>
-for more information.</p></dd>
-
-<dt>Templates, scoping, and digraphs.</dt>
-
-<dd><p>If you have a class in 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 this here fails with a
-parser error: <code>std::vector<::X></code>.
-</p>
-
-<p>
-The reason is that the standard mandates that the sequence
-<code><:</code> is treated as if it were the token
-<code>[</code>, and the parser then reports a parse error before the
-character <code>:</code> (by which it means the second
-colon). There are several such combinations of characters, and
-they are called <em>digraphs</em>.
-</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>
-
-
-</dl>
-
-<h3><a name="missing">Missing features</a></h3>
-<p>We know some things are missing from G++.</p>
-
-<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>
-
-<dt>Two stage lookup in templates is not implemented.</dt>
-<dd><p>[14.6] specifies how names are looked up inside a template. G++
-does not do this correctly, but for most templates this will not be
-noticeable.</p></dd>
-
-</dl>
-
-<h3><a name="parsing">Parse errors for "simple" code</a></h3>
-
-Up to and including GCC 3.0, the compiler will give "parse error" for
-seemingly simple code, such as
-
-<pre>
-struct A{
- A();
- A(int);
- void func();
-};
-
-struct B{
- B(A);
- B(A,A);
- void func();
-};
-
-void foo(){
- B b(A(),A(1)); //Variable b, initialized with two temporaries
- B(A(2)).func(); //B temporary, initialized with A temporary
-}
-</pre>
-The problem is that GCC starts to parse the declaration of
-<code>b</code> as a function <code>b</code> returning <code>B</code>,
-taking a function returning <code>A</code> as an argument. When it
-sees the 1, it is too late. The work-around in these cases is to add
-additional parentheses around the expressions that are mistaken as
-declarations:
-<pre>
- (B(A(2))).func();
-</pre>
-Sometimes, even that is not enough; to show the compiler that this
-should be really an expression, a comma operator with a dummy argument
-can be used:
-<pre>
- B b((0,A()),A(1));
-</pre>
-<p>
-Another example is the parse error for the <code>return</code>
-statement in</p>
-<pre>
-struct A{};
-
-struct B{
- A a;
- A f1(bool);
-};
-
-A B::f1(bool b)
-{
- if (b)
- return (A());
- return a;
-}
-</pre>
-<p>The problem is that the compiler interprets <code>A()</code> as a
-function (taking no arguments, returning <code>A</code>), and
-<code>(A()</code>) as a cast - with a missing expression, hence the
-parse error. The work-around is to omit the parentheses:</p>
-<pre>
- if (b)
- return A();
-</pre>
-<p>This problem occurs in a number of variants; in <code>throw</code>
-statements, people also frequently put the object in parentheses. The
-exact error also somewhat varies with the compiler version. The
-work-arounds proposed do not change the semantics of the program at
-all; they make them perhaps less readable.</p>
-
-<h3><a name="-O3">Optimization at <code>-O3</code> takes a
-very long time</a></h3>
-<p>At <code>-O3</code>, all functions are candidates for inlining. The
-heuristic used has some deficiencies which show up when allowed such
-freedom. This is g++ specific, as it has an earlier inliner than
-gcc.</p>
-
-</body>
-</html>
projects / msp430-gcc.git / blobdiff