[wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Tobias Burnus]

[-- Attachment #1: Type: text/plain, Size: 621 bytes --]

Update the release notes and the impl.status for some newer
changes: Reverse offload for AMD GCN now works.

Additionally, I thinko for TR11 was fixed (propagating a libgomp.texi
change): the other clauses already support 'strict' as listed elsewhere
(earlier OpenMP version and alreaddy implemented in GCC).

Comments? Suggestions?

Tobias
-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

[-- Attachment #2: www-omp-update.diff --]
[-- Type: text/x-patch, Size: 3906 bytes --]

OpenMP update for gcc-13/changes.html + projects/gomp/

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 5dbcc229..03b51bef 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -60,19 +60,19 @@ a work-in-progress.</p>
 <h2 id="general">General Improvements</h2>
 
 <ul>
   <li id="openmp"><a href="https://gcc.gnu.org/projects/gomp/">OpenMP</a>
   <ul>
     <li>
-      Reverse offload is now supported with nvptx devices. Additionally, the
-      <code>requires</code> handling has been improved and all clauses are
-      now accepted. If a requirement cannot be fulfilled for an accessible
-      device, this device is excluded from the list of available devices. This
-      may imply that the only device left is the host (the initial device).
-      In particular, <code>requires_offload</code> is currently unsupported on
-      AMD GCN devices while <code>unified_address</code> and
+      Reverse offload is now supported with nvptx and AMD GCN devices.
+      Additionally, the <code>requires</code> handling has been improved and
+      all clauses are now accepted. If a requirement cannot be fulfilled for
+      an accessible device, this device is excluded from the list of
+      available devices. This may imply that the only device left is the host
+      (the initial device).
+      In particular, <code>unified_address</code> and
       <code>unified_shared_memory</code> are unsupported by all non-host
       devices.
     </li>
     <li>
       OpenMP 5.0: Fortran now supports some non-rectangular loop nests; for
       C/C++, the support was added in GCC 11.
diff --git a/htdocs/projects/gomp/index.html b/htdocs/projects/gomp/index.html
index b2b3b0c8..3ef4f502 100644
--- a/htdocs/projects/gomp/index.html
+++ b/htdocs/projects/gomp/index.html
@@ -312,14 +312,14 @@ than listed, depending on resolved corner cases and optimizations.</p>
       <a href="../../gcc-12/changes.html#languages">GCC&nbsp;12</a><br>
       <a href="../../gcc-13/changes.html#languages">GCC&nbsp;13</a>
     </td>
     <td>
       (<code>atomic_default_mem_order</code>)<br>
       (<code>dynamic_allocators</code>)<br>
-      complete but no non-host devices provides <code>unified_address</code>,
-      <code>unified_shared_memory</code> or <code>reverse_offload</code>
+      complete but no non-host devices provides <code>unified_address</code> or
+      <code>unified_shared_memory</code>
     </td>
   </tr>
   <tr>
     <td><code>conditional</code> modifier to <code>lastprivate</code> clause</td>
     <td class="supported"><a href="../../gcc-10/changes.html#languages">GCC&nbsp;10</a></td>
     <td></td>
@@ -429,13 +429,13 @@ than listed, depending on resolved corner cases and optimizations.</p>
     <td class="supported">
       <a href="../../gcc-12/changes.html#languages">GCC&nbsp;12</a><br>
       <a href="../../gcc-13/changes.html#languages">GCC&nbsp;13</a>
     </td>
     <td>
       Reverse offload unsupported<br>
-      See comment for <code>requires</code>
+      Reverse offload supported</code>
     </td>
   </tr>
   <tr>
     <td>Mapping C/C++ pointer variables and to assign the address of device memory mapped by an array section</td>
     <td class="supported"><a href="../../gcc-12/changes.html#languages">GCC&nbsp;12</a></td>
     <td></td>
@@ -1059,14 +1059,13 @@ error.</p>
   <tr>
     <td><code>omp_get_max_progress_width</code> runtime routine
     <td class="unsupported">No</td>
     <td></td>
   </tr>
   <tr>
-    <td><code>strict</code> modifier keyword to <code>num_threads</code>, <code>num_tasks</code>
-      and <code>grainsize</code>
+    <td><code>strict</code> modifier keyword to <code>num_threads</code>
     <td class="unsupported">No</td>
     <td></td>
   </tr>
   <tr>
     <td><code>memscope</code> clause to <code>atomic</code> and <code>flush</code>
     <td class="unsupported">No</td>

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Gerald Pfeifer]

On Wed, 22 Feb 2023, Tobias Burnus wrote:
> Comments? Suggestions?

OpenMP update for gcc-13/changes.html + projects/gomp/


--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
+      Reverse offload is now supported with nvptx and AMD GCN devices.

Would it make sense to sort AMD GCN and nvptx alphabetically (and in turn 
switch the order)?


From a wwwdocs perspective the changes look fine.

Thanks,
Gerald

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Tobias Burnus]

On 23.02.23 00:29, Gerald Pfeifer wrote:
> On Wed, 22 Feb 2023, Tobias Burnus wrote:
>> Comments? Suggestions?
> Would it make sense to sort AMD GCN and nvptx alphabetically (and in turn
> switch the order)?
>
>  From a wwwdocs perspective the changes look fine.

Thanks for having a look. I swapped them and have decided to go ahead
and commit the patch:

https://gcc.gnu.org/gcc-13/changes.html and
https://gcc.gnu.org/projects/gomp/

have them applied if someone want to proofread by looking at the
rendered code.

Thanks,

Tobias

PS: I also removed a stray </code>, but admittedly only after the
commit. I found it by manually running those through the w3 validator
site. However, I did not see an automatic email, either it takes longer
or does it no longer run? It did in the past!

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Gerald Pfeifer]

On Thu, 23 Feb 2023, Tobias Burnus wrote:
> PS: I also removed a stray </code>, but admittedly only after the
> commit. I found it by manually running those through the w3 validator
> site. However, I did not see an automatic email, either it takes longer
> or does it no longer run? It did in the past!

You are right, and this is a sore / sad point: validator.w3.org that we
used in the past now only supports interactive sessions. And they even
broke support for the Referer header, so I also had to remove the checking 
link I had embedded in all of our pages.

These days I invoke the validator (via a version of the original script) 
when I see a commit. Which indeed leads to many orders of magnitude longer 
delays.

Sadly I don't have a better alternative. :-(

Gerald

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Benson Muite]

On 2/24/23 04:02, Gerald Pfeifer wrote:
> On Thu, 23 Feb 2023, Tobias Burnus wrote:
>> PS: I also removed a stray </code>, but admittedly only after the
>> commit. I found it by manually running those through the w3 validator
>> site. However, I did not see an automatic email, either it takes longer
>> or does it no longer run? It did in the past!
> 
> You are right, and this is a sore / sad point: validator.w3.org that we
> used in the past now only supports interactive sessions. And they even
> broke support for the Referer header, so I also had to remove the checking 
> link I had embedded in all of our pages.
> 
> These days I invoke the validator (via a version of the original script) 
> when I see a commit. Which indeed leads to many orders of magnitude longer 
> delays.
> 
> Sadly I don't have a better alternative. :-(
> 
Could one of the following be used or used to generate a better workflow:
https://html-validate.org/usage/cli.html - written in Javascript, but
has a command line interface
https://github.com/validator/validator - packaged, but a little
cumbersome, may need a wrapper
https://github.com/w3c-validators/w3c_validators - Wrapper written in
Ruby, with a nice interface to validate a local file

Re: [wwwdocs, patch] OpenMP update for gcc-13/changes.html + projects/gomp/

[Benson Muite]

On 2/24/23 10:32, Benson Muite via Gcc-patches wrote:
> On 2/24/23 04:02, Gerald Pfeifer wrote:
>> On Thu, 23 Feb 2023, Tobias Burnus wrote:
>>> PS: I also removed a stray </code>, but admittedly only after the
>>> commit. I found it by manually running those through the w3 validator
>>> site. However, I did not see an automatic email, either it takes longer
>>> or does it no longer run? It did in the past!
>>
>> You are right, and this is a sore / sad point: validator.w3.org that we
>> used in the past now only supports interactive sessions. And they even
>> broke support for the Referer header, so I also had to remove the checking 
>> link I had embedded in all of our pages.
>>
>> These days I invoke the validator (via a version of the original script) 
>> when I see a commit. Which indeed leads to many orders of magnitude longer 
>> delays.
>>
>> Sadly I don't have a better alternative. :-(
>>
> Could one of the following be used or used to generate a better workflow:
> https://html-validate.org/usage/cli.html - written in Javascript, but
> has a command line interface
> https://github.com/validator/validator - packaged, but a little
> cumbersome, may need a wrapper
> https://github.com/w3c-validators/w3c_validators - Wrapper written in
> Ruby, with a nice interface to validate a local file
> 
html-tidy could work well. Written in C. A typical session from Git
Sources following [1]:

git pull
cd gcc
./configure
mkdir HTML
makeinfo --html --no-split -Idoc -Idoc/include -o HTML doc/gcc.texi
tidy -f HTML/errs.txt -imu HTML/gcc.html

Typical current reported errors are
line 23080 column 22 - Warning: nested emphasis <samp>
line 40445 column 11 - Warning: nested emphasis <code>
line 3541 column 1 - Warning: <span> anchor "index-g_002b_002b" already
defined
line 54489 column 1 - Warning: <table> lacks "summary" attribute


[1]
https://unix.stackexchange.com/questions/493013/how-to-build-the-gcc-html-documentation-from-source-into-a-single-page