On 04/03/14 22:32 +0000, Jonathan Wakely wrote:
I've added an initial "Porting to GCC 4.9" page at
http://gcc.gnu.org/gcc-4.9/porting_to.html
So far it only contains a couple of C++ changes that caused some
failures during mass rebuilds, other additions are welcome.
The attached patch adds some more changes (thanks to Jakub for the
OpenMP one) and links to the porting guide form gcc-4.9/changes.html
Index: changes.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- changes.html 4 Mar 2014 05:40:02 -0000 1.59
+++ changes.html 7 Mar 2014 18:04:49 -0000 1.60
@@ -35,6 +35,14 @@
</li>
</ul>
+ <p>
+ More information on porting to GCC 4.9 from previous versions
+ of GCC can be found in
+ the <a href="http://gcc.gnu.org/gcc-4.9/porting_to.html";>porting
+ guide</a> for this release.
+ </p>
+
+
<h2>General Optimizer Improvements</h2>
<ul>
@@ -217,8 +225,8 @@
</li>
<li>
G++ supports the <a href="../projects/cxx1y.html">C++1y</a> [[deprecated]]
- attribute modulo bugs in the underying [[gnu::deprecated]] attribute.
Classes
- and functions can be marked deprecated and
+ attribute modulo bugs in the underlying [[gnu::deprecated]] attribute.
Classes
+ and functions can be marked deprecated and a diagnostic message added:
<blockquote><pre>
class A;
int bar(int n);
Index: porting_to.html
===================================================================
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/porting_to.html,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- porting_to.html 4 Mar 2014 22:28:30 -0000 1.1
+++ porting_to.html 7 Mar 2014 18:04:48 -0000 1.2
@@ -33,13 +33,40 @@
<h3>New warnings</h3>
-->
+<h2>C/C++ language issues</h2>
+
+<h3>Invalid OpenMP #pragma omp end directive now diagnosed</h3>
+
+<p> GCC no longer accepts invalid OpenMP like: </p>
+
+<pre><code>
+ #pragma omp critical
+ foo ();
+ #pragma omp end critical
+</code></pre>
+
+<p>This example now gives the following diagnostic:</p>
+
+<pre>
+t.c:6:19: error: expected ‘declare’ before ‘critical’
+ #pragma omp end critical
+ ^
+</pre>
+
+<p>There is no <code>#pragma omp end critical</code> directive for C/C++
+(whereas for Fortran there is <code>!$omp end critical</code>) but before
+OpenMP 4.0 support was added, this would be diagnosed only with
+<code>-Wunknown-pragmas</code>. As OpenMP 4.0 includes the
+<code>#pragma omp end declare target</code> directive, this is now a parsing
+error.</p>
+
<!--
<h2>C language issues</h2>
-->
<h2>C++ language issues</h2>
-<h3>Shadowing name of exception in catch clause now rejected</h3>
+<h3>Shadowing name of exception in <code>catch</code> handler now rejected</h3>
<p> GCC by default no longer accepts code such as: </p>
@@ -64,40 +91,86 @@
<p>
The standard says the example is ill-formed, so GCC was changed to reject it
-for <a href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31952";>PR 31952</a>.
+for <a href="http://gcc.gnu.org/PR31952";>PR31952</a>.
To fix the error either rename one of the variables or use an additional
nested scope for the second one.
</p>
-<h3>Default arguments on redeclaration of member function of class template no
rejected</h3>
+<h3>Default arguments on redeclaration of member function of class template
now rejected</h3>
<p> GCC by default no longer accepts code such as: </p>
<pre><code>
- template<class T>
+ template<class T>
struct A
{
void f(int);
};
- template<class T>
+ template<class T>
void A<T>::f(int i=0) { }
</code></pre>
<p>This example now gives the following diagnostic:</p>
<pre>
-r.cc:8:21: error: redeclaration of ‘void A<T>::f(int)’ may not have default
arguments [-fpermissive]
+r.cc:8:21: error: redeclaration of ‘void A<T>::f(int)’ may not have
default arguments [-fpermissive]
</pre>
<p>
-The standard says the example is ill-formed, so GCC was changed to reject it.
+The standard says the example is ill-formed, so GCC was changed to reject it
+for <a href="http://gcc.gnu.org/PR54485";>PR54485</a>.
To fix the error the default argument must appear when the member function
is first declared.
</p>
+<h3>Header <code><memory></code> changes</h3>
+
+<p>The contents of the <code><memory></code> header were reorganized to
+allow easier reuse within libstdc++.
+As a result, some code which directly includes headers such as
+<code><bits/shared_ptr.h></code> will no longer compile and may produce
+a diagnostic like:</p>
+<pre>
+/usr/include/c++/4.9.0/bits/shared_ptr_base.h: In member function 'virtual
void* std::_Sp_counted_deleter<_Ptr, _Deleter, _Alloc,
_Lp>::_M_get_deleter(const std::type_info&)’:
+/usr/include/c++/4.9.0/bits/shared_ptr_base.h:479:39: error: must #include
<typeinfo> before using typeid
+ return __ti == typeid(_Deleter) ? &_M_impl._M_del() : nullptr;
+ ^
+</pre>
+
+<p>All <code><bits/xxx.h></code> headers are internal library headers
+and including them directly is not supported and may be made into a hard
+error in a future GCC release.</p>
+
+<h3>Header <code><cstddef></code> changes</h3>
+
+<p>The <code><cstddef></code> header was updated for C++11 support and
+this breaks some libraries which misuse macros meant for internal use by GCC
+only.
+For instance with GMP versions up to 5.1.3, you may see: </p>
+<pre>
+/usr/include/c++/4.9.0/cstddef:51:11: error: '::max_align_t' has not been
declared
+ using ::max_align_t;
+ ^
+</pre>
+<p>Another possible error is:</p>
+<pre>
+someheader.h:99:13: error: 'ptrdiff_t' does not name a type
+</pre>
+<p>A workaround until libraries get updated is to include
+<code><cstddef></code> or <code><stddef.h></code> before any
+headers from that library.</p>
+
+<h3>Functions returning abstract class types</h3>
+
+<p>GCC now checks return types more strictly and will reject declarations of
+functions which return abstract types, including in uninstantiated templates
+and in typedefs to function pointers. Returning an abstract type is not
+possible so the code must be fixed.</p>
+
+
<!--
<h3>Java issues</h3>
-->
