Add async-argument and wait-argument grammar tests on compute constructs

[Ryanpadrone]

Feature

This pull request adds new validation tests for the OpenACC 3.4 specification change that corrected the grammar of compute constructs to use async-argument and wait-argument consistently with the rest of the specification (see Sections 2.5 and 2.16 of the OpenACC 3.4 spec).

The update clarifies that compute constructs such as parallel, serial, and kernels should accept the same async and wait clause grammar used elsewhere in the specification, including:
• async()
• async with no argument
• async with no argument
• wait(queues: ...)
• wait(devnum: ... : ...)
• wait(devnum: ... : queues: ...)

Tests Added

ASYNC T1 – Baseline async expression
Runs a parallel loop using async(q0) where q0 is a nonnegative integer expression (q - q).
Then uses wait with no argument to synchronize execution.
Tests:
•async-argument acceptance on compute constructs
•wait with no argument (wait on all queues)

WAIT T1 – queues modifier
Launches two asynchronous kernels on queues 1 and 2, then runs a third compute construct with:
wait(queues: 1, 2)
Tests:
• queues: modifier in the wait-argument grammar

ASYNC T2 – Default async queue
Uses the runtime API:

acc_set_default_async()
acc_get_default_async()

A compute construct is launched using async with no argument to verify that it executes on the default queue.
Tests:
• implicit async argument behavior
• interaction between compute constructs and the default async queue.

WAIT T2 – devnum modifier
Uses:
wait(devnum: 0 : 1)
Tests:
• devnum: mpdifier in the wait-argument grammar.

WAIT T3 – devnum + queues
Uses the full wait grammar:
wait(devnum: 0 : queues: 1)
Tests:
• full wait-argument grammar path.

ASYNC T3 – Explicit acc_async_sync
Uses:
async(acc_async_sync)
Tests explicit use of the special async value rather than relying on implicit behavior.

ASYNC T4 – Explicit acc_async_noval
Uses:
async(acc_async_noval)
Tests explicit use of the special async value rather than relying on the shorthand async with no argument.

Compiler Testing Results

GCC 15.2.0:

*C:
**WAIT T1 - wait(queues:...):

error: ‘queues’ undeclared (first use in this function)
error: expected ')' before ':' token

The compiler interprets queues as an undeclared identifier rather than the 'queues:' modifier defined in the OpenACC 3.4 wait-argument grammar.

**ASYNC T2 - Default Async Runtime API

error: implicit declaration of function ‘acc_set_default_async’
error: implicit declaration of function ‘acc_get_default_async’

These functions are part of the OpenACC runtime API used to set and retrieve the default asynchronous queue.
The errors suggest that these runtime functions are not visible through the default OpenACC headers in this configuration

**WAIT T2 - wait(devnum:...)
Same error as T2 - the compiler interprets devnum as a variable rather than recognize the 'devnum:' modifier in the OpenACC 3.4 grammar

**WAIT T3 - wait(devnum:... : queues: ...)
Reports similar errors:

error: ‘devnum’ undeclared
error: expected ')' before ':' token

*C++
**WAIT T1 - wait(queues: ...)
error: ‘queues’ was not declared in this scope

**ASYNC T2 - Default Async Runtime API

error: ‘acc_set_default_async’ was not declared in this scope
error: ‘acc_get_default_async’ was not declared in this scope

**WAIT T2 - wait(devnum: ...)
error: ‘devnum’ was not declared in this scope

**WAIT T3 - wait(devnum: ... : queues: ...)
error: ‘devnum’ was not declared in this scope

These errors indicate that the parser is not recognizing 'queues:' and 'devnum:' as OpenACC clause modifiers

*Fortran
**WAIT T1 - wait(queues: ...)
Error: Syntax error in OpenACC expression list
This indicates that the compiler does not recognize the queues: modifier inside the wait clause.

After rejecting the wait(...) syntax, the compiler also reports:

Unexpected !$ACC END PARALLEL LOOP statement
Expecting !$ACC END DATA

These errors appear to be parse errors caused by the compiler failing to recognize the opening directive once the wait-argument syntax is rejected

**ASYNC T2 - Default Async Runtime API
Function 'acc_get_default_async' has no IMPLICIT type
This indicates that the runtime API function is not recognized through the OpenACC modules or headers in this environment

NVIDIA 26.1

*C/C++
**WAIT T1 - wait(queues: ...)

error: identifier "queues" is undefined
error: expected a ")"

**WAIT T2 - wait(devnum: ...)

error: identifier "devnum" is undefined
error: expected a ")"

**WAIT T3 - wait(devnum:... : queues:...)

error: identifier "devnum" is undefined
error: expected a ")"

These errors indicate that the NVHPC parser does not currently recognize the queues: or devnum: modifiers in the wait clause

*Fortran
NVHPC reports:

acc_set_default_async is use associated with openacc_la and cannot be redeclared
acc_get_default_async is use associated with openacc_la and cannot be redeclared

These errors occur because NVHPC already provides interfaces for these runtime API functions through the OpenACC module

**WAIT T1/T2/T3 - wait grammar
NVHPC also reports errors such as:
Syntax error at or near :
for directives using:
• wait(queues: ...)
• wait(devnum: ...)
• wait(devnum: ... : queues: ...)

Cray 18.0.0

*Fortran
**WAIT T1 - wait(queues:...)
Cray reports:

explicit type must be specified for data object "QUEUES"
")" was expected but found ":"

**WAIT T2 - wait(devnum:...)

explicit type must be specified for data object "DEVNUM"
")" was expected but found ":"

**WAIT T3 - wait(devnum:... : queues: ...)
Similar errors occur, again indicating that the compiler is interpreting queues and devnum as identifiers rather than directive modifiers.

Summary

These tests validate the OpenACC 3.4 grammar correction for compute constructs using async-argument and wait-argument

Testing across GCC, NVHPC, and Cray compilers shows that several implementations currently reject syntax that is valid according to the OpenACC 3.4 Specification, particularly the extended wait clause grammar

These tests help identify the discrepancies between the specification and current compiler implementations and provide useful conformance tests for future compiler updates.