libgomp.texi: Improve "OpenACC Environment Variables"

I was recently suggesting someone to use ACC_DEVICE_TYPE; I did not point to the
documentation it only contains the title:
   https://gcc.gnu.org/onlinedocs/libgomp/ACC_005fDEVICE_005fTYPE.html

Admittedly, there is also "Reference:" pointing to the OpenACC specification,
but the latter just states:

"The allowed values of this environment variable are implementation-defined. See the
release notes for currently-supported values of this environment variable."

Thus, I now added documentation for the three ACC_ env vars.
I removed GCC_ACC_NOTIFY as it does not seem to exist - and it looks as if it
never did ... (The Nvidia compiler seems to support ACC_NOTIFY with a similar
usage as GOMP_DEBUG and GCN_DEBUG). It was added in GCC 6, which implies that
it also won't be added again. (I also checked OG9 and OG13 and neither contained
it; I don't know whether some older OG did.)

Comments?

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

On 10/14/23 13:51, Tobias Burnus wrote:

> @@ -5003,6 +5001,17 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
>  @node ACC_DEVICE_TYPE
>  @section @code{ACC_DEVICE_TYPE}
>  @table @asis
> +@item @emph{Description}:
> +Control the default device type to use when executing compute regions.
> +If unset, the code can be run on any device type, favoring a non-host
> +device type.
> +
> +Supported value in GCC (if compiled in) are

s/value/values/

> +@itemize
> +@item @code{host}
> +@item @code{nvidia}
> +@item @code{radeon}
> +@end itemize
>  @item @emph{Reference}:
>  @uref{https://www.openacc.org, OpenACC specification v2.6}, section
>  4.1.
> @@ -5013,6 +5022,10 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
>  @node ACC_DEVICE_NUM
>  @section @code{ACC_DEVICE_NUM}
>  @table @asis
> +@item @emph{Description}:
> +Control which device, identified by device number, is the default device.
> +The number must be a nonnegative integer number less that the number of

Ummm, too many "number"s!

How about rephrasing that as
The value must be a nonnegative integer less than the number of....

> +devices.  If unset, device number zero is used.
>  @item @emph{Reference}:
>  @uref{https://www.openacc.org, OpenACC specification v2.6}, section
>  4.2.
> @@ -5023,6 +5036,11 @@ The variable @env{GCC_ACC_NOTIFY} is used for diagnostic purposes.
>  @node ACC_PROFLIB
>  @section @code{ACC_PROFLIB}
>  @table @asis
> +@item @emph{Description}:
> +Semicolon separated list of dynamic libraries to be loaded as profiling library.

s/Semicolon separated/Semicolon-separated/

There's also a semantic issue with "list of dynamic libraries" (plural) and 
"profiling library" (singular).  Are they all separately profiling libraries, 
or does the entire list constitute a single logical profiling library and its 
dependencies?

> +The library file is found as described by the documentation of @code{dlopen} of

Probably s/The/Each/?

> +your operating system.  Each library must implement at least the routine
> +@code{acc_register_library} routine.

Again, I'm not sure if this applies to every library in the list, or just that 
some library in the list must provide this routine.

-Sandra

Hi Sandra,

thanks for the comments.

On 15.10.23 00:46, Sandra Loosemore wrote:
>> +Semicolon separated list of dynamic libraries to be loaded as
>> profiling library.
>
> s/Semicolon separated/Semicolon-separated/
>
> There's also a semantic issue with "list of dynamic libraries"
> (plural) and "profiling library" (singular).  Are they all separately
> profiling libraries, or does the entire list constitute a single
> logical profiling library and its dependencies?

No, each library works as separate "profiling library", everything else
does not make much sense.

Updated patch attached - I hope it is now clearer.

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

On 10/15/23 04:40, Tobias Burnus wrote:
> Hi Sandra,
> 
> thanks for the comments.
> 
> On 15.10.23 00:46, Sandra Loosemore wrote:
>>> +Semicolon separated list of dynamic libraries to be loaded as
>>> profiling library.
>>
>> s/Semicolon separated/Semicolon-separated/
>>
>> There's also a semantic issue with "list of dynamic libraries"
>> (plural) and "profiling library" (singular).  Are they all separately
>> profiling libraries, or does the entire list constitute a single
>> logical profiling library and its dependencies?
> 
> No, each library works as separate "profiling library", everything else
> does not make much sense.
> 
> Updated patch attached - I hope it is now clearer.

Yup, this version is fine to commit.

-Sandra