public inbox for gcc-cvs-wwwdocs@sourceware.org help / color / mirror / Atom feed
From: Gerald Pfeifer <gerald@sourceware.org> To: gcc-cvs-wwwdocs@gcc.gnu.org Subject: gcc-wwwdocs branch master updated. ff5db291b5b1a73adb515abdb4f92e0d0b54c556 Date: Sun, 15 Oct 2023 14:40:03 +0000 (GMT) [thread overview] Message-ID: <20231015144003.704EE3858D33@sourceware.org> (raw) 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 < 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
reply other threads:[~2023-10-15 14:40 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20231015144003.704EE3858D33@sourceware.org \ --to=gerald@sourceware.org \ --cc=gcc-cvs-wwwdocs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).