This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [www-patch] bugs.html rewrite,part 6: section about upgrading the compiler


On 19 Nov, Gerald Pfeifer wrote:
> On Wed, 19 Nov 2003, Volker Reichelt wrote:
>> Well, the sentence would get way too long for my taste (about 4 lines in
>> the HTML source). I'd rather suggest the following:
>> 
>> + <h4>ABI changes</h4>
>> + 
>> + <p>The application binary interface (ABI) defines how the elements of
>> + classes are laid out, how functions are called, how function names are
>> + mangled etc.  It usually changes with each major release (i.e. when the
>> + first or second part of the version number changes).  You <em>must</em>
>> + recompile all C++ libraries, or you risk linker errors or crashing
>> + programs.  However, the ABI is not changed with bug-fix releases (i.e.
>> + when the third part of the version number changes).  The code should be
>> + binary compatible among these versions.</p>
> 
> I like that one; it's much better than what I suggested. ;-)

Ok.

>> Btw, shouldn't we rather write "risk linker errors or
>> malfunctioning/crashing programs" instead of just "... crashing
>> programs"?
> 
> Yup. Perhaps just "malfunctioning"?

Ok.

>> I found another glitch in the patch: I forgot to update the heading for
>> the new section in the table of contents. This will be fixed in the
>> final version.
> 
> Fine, thanks!  (And please complain to the original reviewer for not
> spotting that. <g>)

I just wanted to test you. ;-)

> Gerald

So here's the version I just committed.

Regards,
Volker

==============================================================================
--- bugs.html	Wed Nov 19 13:40:39 2003
+++ bugs.html	Wed Nov 19 13:37:06 2003
@@ -28,7 +28,6 @@ GCC Bugs
   <ul>
   <li><a href="#cxx">C++</a>
     <ul>
-    <li><a href="#cxx-abi">ABI bugs</a></li>
     <li><a href="#missing">Missing features</a></li>
     <li><a href="#parsing">Parse errors for "simple" code</a></li>
     </ul>
@@ -42,8 +41,7 @@ GCC Bugs
   <li><a href="#nonbugs_c">C</a></li>
   <li><a href="#nonbugs_cxx">C++</a>
     <ul>
-    <li><a href="#updating">Common problems updating from G++ 2.95 to
-      G++ 3.0</a></li>
+    <li><a href="#upgrading">Common problems when upgrading the compiler</a></li>
     </ul>
   </li>
   </ul>
@@ -302,28 +300,15 @@ In particular, bugs caused by invalid co
 
 <h2><a name="cxx">C++</a></h2>
 
-<h3><a name="cxx-abi">ABI bugs</a></h3>
-
-<p>GCC 3.0 had a new ABI, which affected class layout, function mangling and
-calling conventions. We had intended it to be complete, but 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>Up to (and including) GCC 3.3 we did not implement non-trivial
-covariant returns.  This has been addressed for GCC 3.4.</dd>
-
-</dl>
-
 <h3><a name="missing">Missing features</a></h3>
 <p>We know some things are missing from G++.</p>
 
 <dl>
 
+<dt>Covariant return types</dt>
+<dd><p>Up to (and including) GCC 3.3 we did not implement non-trivial
+covariant returns.  This has been addressed for GCC 3.4.</p></dd>
+
 <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
@@ -333,11 +318,6 @@ workaround is simply to place all defini
 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>
@@ -710,31 +690,49 @@ a parse error before the character <code
 and the scope operator.</p></dd>
 </dl>
 
-<h3><a name="updating">Common problems updating from G++ 2.95 to G++
-3.0</a></h3>
+<h3><a name="upgrading">Common problems when upgrading the compiler</a></h3>
+
+<h4>ABI changes</h4>
+
+<p>The application binary interface (ABI) defines how the elements of
+classes are laid out, how functions are called, how function names are
+mangled etc.  It usually changes with each major release (i.e. when the
+first or second part of the version number changes).  You <em>must</em>
+recompile all C++ libraries, or you risk linker errors or malfunctioning
+programs.  However, the ABI is not changed with bug-fix releases (i.e.
+when the third part of the version number changes).  The code should be
+binary compatible among these versions.</p>
 
-<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>
+<h4>Standard conformance</h4>
 
-<p>We have also implemented some of the core and library defect reports
+<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://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html";>http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html</a>
 &amp;
-<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>
+<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>
+<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 upcoming 3.4 version (with its
+new C++ parser).</p>
 
-<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>
+<h4>New in GCC 3.0</h4>
 
-<li>The standard library is much more conformant, and uses the
-<code>std::</code> namespace.</li>
+<ul>
 
-<li><code>std::</code> is now a real namespace, not an alias for
-<code>::</code>.</li>
+<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.
@@ -755,35 +753,101 @@ doesn't exist, you need to recompile lib
 
 </ul>
 
-<p>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,</p>
+<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::strcmp</code> at the call. This is the most explicit
+<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::strcmp;</code> somewhere before the call. You
+<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.
+<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>
+<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>New in GCC 3.4</h4>
 
-<p>In addition to the problems listed above, the manual contains a section on
-<a href="http://gcc.gnu.org/onlinedocs/gcc/C---Misunderstandings.html";>Common
-Misunderstandings with GNU C++</a>.</p>
+<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 &lt;typename&gt; struct A
+{
+    typedef int X;
+};
 
+template &lt;typename T&gt; struct B
+{
+    A&lt;T&gt;::X          x;  // error
+    typename A&lt;T&gt;::X y;  // OK
+};
+
+B&lt;void&gt; b;
+</pre></blockquote></li>
+
+<li>For similar reasons, the following code now requires the
+<code>template</code> keyword, see [14.2]:
+<blockquote><pre>
+template &lt;typename&gt; struct A
+{
+    template &lt;int&gt; struct X {};
+};
+
+template &lt;typename T&gt; struct B
+{
+    typename A&lt;T&gt;::X&lt;0&gt;          x;  // error
+    typename A&lt;T&gt;::template X&lt;0&gt; y;  // OK
+};
+
+B&lt;void&gt; 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 &lt;typename T&gt; int foo()
+{
+    return i;  // error
+}
+</pre></blockquote></li>
+
+<li>This also affects members of base classes, see [14.6.2]:
+<blockquote><pre>
+template &lt;typename&gt; struct A
+{
+    int i, j;
+};
+
+template &lt;typename T&gt; struct B : A&lt;T&gt;
+{
+    int foo1() { return i; }       // error
+    int foo2() { return this-&gt;i; } // OK
+    int foo3() { return B&lt;T&gt;::i; } // OK
+    int foo4() { return A&lt;T&gt;::i; } // OK
+
+    using A&lt;T&gt;::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---Misunderstandings.html";>Common
+Misunderstandings with GNU C++</a>.</p>
 
 </body>
 </html>
==============================================================================



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]