gcc-wwwdocs branch master updated. ff5db291b5b1a73adb515abdb4f92e0d0b54c556

gcc-wwwdocs branch master updated. ff5db291b5b1a73adb515abdb4f92e0d0b54c556

[Gerald Pfeifer]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gcc-wwwdocs".

The branch, master has been updated
       via  ff5db291b5b1a73adb515abdb4f92e0d0b54c556 (commit)
      from  a6867d6b98ff0413d5fec21876f7f693df38290c (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
commit ff5db291b5b1a73adb515abdb4f92e0d0b54c556
Author: Gerald Pfeifer <gerald@pfeifer.com>
Date:   Sun Oct 15 16:39:36 2023 +0200

    gcc-9: Editorial changes to porting_to.html

diff --git a/htdocs/gcc-9/porting_to.html b/htdocs/gcc-9/porting_to.html
index 796c402e..fc85dae2 100644
--- a/htdocs/gcc-9/porting_to.html
+++ b/htdocs/gcc-9/porting_to.html
@@ -64,22 +64,23 @@ and provide solutions. Let us know if you have suggestions for improvements!
   that <code>const</code> qualified variables without <code>mutable</code>
   member are predetermined shared, but as an exception may be specified
   in the <code>firstprivate</code> clause.  OpenMP 4.0 dropped this rule,
-  but in the hope that the incompatible change will be reverted GCC kept
-  implementing the previous behavior.  Now that for OpenMP 5.0 it has been
+  but in the hope that this incompatible change will be reverted GCC kept
+  the previous behavior.  Now that for OpenMP 5.0 it has been
   confirmed this is not going to change, GCC 9 started implementing the
-  OpenMP 4.0 and later behavior.  When not using <code>default</code>
+  OpenMP 4.0 and later behavior.  When not using a <code>default</code>
   clause or when using <code>default(shared)</code>, this makes no
-  difference, but if using <code>default(none)</code>, previously the
-  choice was not specify the <code>const</code> qualified variables
-  on the construct at all, or specify in <code>firstprivate</code> clause.
-  In GCC 9 as well as for OpenMP 4.0 compliance, those variables need
-  to be specified on constructs in which they are used, either in
-  <code>shared</code> or in <code>firstprivate</code> clause.  Specifying
-  them in <code>firstprivate</code> clause is one way to achieve
-  compatibility with both older GCC versions and GCC 9, another option
+  difference. When using <code>default(none)</code>, previously the
+  choice was not to specify <code>const</code> qualified variables
+  on the construct at all, or specify them in the
+  <code>firstprivate</code> clause.
+  In GCC 9 as well as for OpenMP 4.0 compliance those variables need
+  to be specified on constructs in which they are used, either in a
+  <code>shared</code> or in a <code>firstprivate</code> clause.  Specifying
+  them in a <code>firstprivate</code> clause is one way to achieve
+  compatibility with both older GCC versions and GCC 9. Another option
   is to drop the <code>default(none)</code> clause.  In C++,
   <code>const</code> variables with constant initializers which are not
-  odr-used in the region, but replaced with their constant initializer
+  odr-used in the region, but replaced with their constant initializer,
   are not considered to be referenced in the region for
   <code>default(none)</code> purposes.
 </p>
@@ -93,8 +94,8 @@ and provide solutions. Let us know if you have suggestions for improvements!
         for (int i = 0; i &lt; a; i += b)
           ;
         // The above used to compile with GCC 8 and older, but will
-        // not anymore with GCC 9.  firstprivate(a, b) clause needs
-        // to be added for C, for C++ it could be just firstprivate(a)
+        // not anymore with GCC 9. A firstprivate(a, b) clause needs
+        // to be added for C; for C++ it could be just firstprivate(a)
         // to make it compatible with all GCC releases.
       }
       const int huge_array[1024] = { ... };
@@ -104,7 +105,7 @@ and provide solutions. Let us know if you have suggestions for improvements!
           use (huge_array[i]);
         // Similarly, this used to compile with GCC 8 and older and
         // will not anymore.  Adding firstprivate(huge_array) is
-        // probably undesirable here, so, either
+        // probably undesirable here, so either
         // default(none) shared(huge_array) should be used and it will
         // only support GCC 9 and later, or default(none) should be
         // removed and then it will be compatible with all GCC releases

-----------------------------------------------------------------------

Summary of changes:
 htdocs/gcc-9/porting_to.html | 31 ++++++++++++++++---------------
 1 file changed, 16 insertions(+), 15 deletions(-)


hooks/post-receive
-- 
gcc-wwwdocs