Hi! The following patch 1) mentions (partial) OpenMP 5.0 support and __builtin_convertvector in c-family section of gcc-9/changes.html 2) mentions C++2a progress in similar way how we've done it in gcc-8/changes.html (the list doesn't include all features, feel free to suggest what should go out of that list or be added and with what wording, some of the cxx-status.html feature names don't look usable in the list to me 3) lists std::is_constant_evaluated as implemented in cxx-status.html 4) adds beginning of gcc-9/porting_to.html , so far just mentions there the lifetime of automatic compound literals
Ok for wwwdocs? --- htdocs/gcc-9/changes.html.jj 2019-01-11 13:09:40.469122800 +0100 +++ htdocs/gcc-9/changes.html 2019-01-11 14:22:42.944333728 +0100 @@ -65,7 +65,21 @@ a work-in-progress.</p> <!-- <h3 id="brig">BRIG (HSAIL)</h3> --> -<!-- <h3 id="c-family">C family</h3> --> +<h3 id="c-family">C family</h3> +<ul> + <li>Version 5.0 of the <a href="https://www.openmp.org/specifications/"; + >OpenMP specification</a> is now partially supported in the C and C++ + compilers. For details which features of OpenMP 5.0 are and which are + not supported in the GCC 9 release see + <a href="https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00628.html";>this mail</a>. + </li> + + <li>New extensions: + <ul> + <li><code>__builtin_convertvector</code> built-in for vector conversions + has been added. </li> + </ul></li> +</ul> <h3 id="cxx">C++</h3> <ul> @@ -79,6 +93,22 @@ a work-in-progress.</p> dangling pointer, such as returning or assigning from a temporary list. </li> </ul></li> + + <li> + The C++ front end has experimental support for some of the upcoming C++2a + draft features with the <code>-std=c++2a</code> or <code>-std=gnu++2a</code> + flags, including range-based for statements with initializer, + less eager instantiation of constexpr functions, default constructible and + assignable stateless lambdas, lambdas in unevaluated contexts, language + support for empty objects, allow pack expansion in lambda init-capture, + likely and unlikely attributes, class types in non-type template + parameters, allowing virtual function calls in constant expressions, + explicit(bool), signed integers are two's complement, + <code>std::is_constant_evaluated</code>, nested inline namespaces, etc. + For a full list of new features, + see <a href="../projects/cxx-status.html#cxx2a">the C++ + status page</a>. + </li> </ul> <h4 id="libstdcxx">Runtime Library (libstdc++)</h4> --- htdocs/projects/cxx-status.html.jj 2019-01-11 13:09:41.475106482 +0100 +++ htdocs/projects/cxx-status.html 2019-01-11 14:24:06.524979265 +0100 @@ -280,7 +280,7 @@ <tr> <td> std::is_constant_evaluated </td> <td><a href="http://wg21.link/p0595r2";>P0595R2</a></td> - <td class="unsupported"> No </td> + <td class="supported"> 9 </td> <td> </td> </tr> <tr> --- htdocs/gcc-9/porting_to.html.jj 2019-01-11 13:29:23.291922307 +0100 +++ htdocs/gcc-9/porting_to.html 2019-01-11 13:23:03.831090097 +0100 @@ -0,0 +1,72 @@ +<!DOCTYPE html> +<html lang="en"> + +<head> +<title>Porting to GCC 9</title> +<link rel="stylesheet" type="text/css" href="https://gcc.gnu.org/gcc.css"; /> +</head> + +<body> +<h1>Porting to GCC 9</h1> + +<p> +The GCC 9 release series differs from previous GCC releases in +<a href="changes.html">a number of ways</a>. Some of these are a result +of bug fixing, and some old behaviors have been intentionally changed +to support new standards, or relaxed in standards-conforming ways to +facilitate compilation or run-time performance. +</p> + +<p> +Some of these changes are user visible and can cause grief when +porting to GCC 9. This document is an effort to identify common issues +and provide solutions. Let us know if you have suggestions for improvements! +</p> + + +<!-- +<h2 id="cpp">Preprocessor issues</h2> +--> + +<h2 id="c">C language issues</h2> + +<h3 id="complit">Block scope compound literal's lifetime</h3> + +<p> + The C standard says that compound literals which occur inside of the body + of a function have automatic storage duration associated with the + enclosing block. Older GCC releases were putting such compound literals + into the scope of the whole function, so their lifetime actually ended + at the end of containing function. This has been fixed in GCC 9. + Code that relied on this extended lifetime needs to be fixed, move the + compound literals to whatever scope they need to accessible in. +</p> + <pre><code> + struct S { int a, b; }; + int foo(void) { + // The following line no longer compiles + struct S *p = &({ (struct S) { 1, 2 }; }); + struct S *q; + { + q = &(struct S) { 3, 4 }; + } + // This is invalid use after lifetime of the compound literal + // ended. + return q->b; + } + </code></pre> + +<!-- +<h2 id="cxx">C++ language issues</h2> +--> + +<!-- +<h2 id="fortran">Fortran language issues</h2> +--> + +<!-- +<h2 id="links">Links</h2> +--> + +</body> +</html> Jakub
