Changeset 1464 for branches/GNU/src/gcc/bugs.html

Timestamp:

Sep 7, 2004, 3:33:15 AM (21 years ago)

Author:

bird

Message:

GCC v3.3.4 - official sources.

File:

• branches/GNU/src/gcc/bugs.html (modified) (7 diffs, 1 prop)

branches/GNU/src/gcc/bugs.html

@@ -30 +30 @@
     <ul>
     <li><a href="#missing">Missing features</a></li>
-    <li><a href="#fixed34">Bugs fixed in the upcoming 3.4 series</a></li>
+    <li><a href="#fixed34">Bugs fixed in the 3.4 series</a></li>
     </ul>
   </li>
@@ -316 +316 @@
 </dl>
 
-<h3><a name="fixed34">Bugs fixed in the upcoming 3.4 series</a></h3>
+<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.
@@ -443 +443 @@
 others.</p>
 
-<p>The is the result of <em>rounding</em>: The computer cannot
+<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
@@ -686 +686 @@
 ::X&gt;</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&amp;);   // private copy ctor
+};
+
+A makeA(void);
+void foo(const A&amp;);
+
+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>
 
@@ -692 +735 @@
 <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>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="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>
@@ -708 +765 @@
 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://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html">http://www.open-std.org/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://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>
 
@@ -721 +778 @@
 
 <p>Two milestones in standard conformance are GCC 3.0 (including a major
-overhaul of the standard library) and the upcoming 3.4.0 version (with its
-new C++ parser).</p>
+overhaul of the standard library) and the 3.4.0 version (with its new C++
+parser).</p>
 
 <h4>New in GCC 3.0</h4>