Hi Thomas,


Thomas Schwinge wrote:
> On 2024-02-27T20:11:30+0100, Tobias Burnus<tburnus@baylibre.com>  wrote:
>> The attached patch updates the manual to match OpenACC 3.3
>> specification for the implemented routines.
> But not update references to OpenACC 3.3, too?

As the change is not really visible (except when using Fortran 
keywords), it was not really clear to me whether the reference should be 
either changed to *or* augmented by the OpenACC 3.1 *or* 3.3 
specification reference.

What do you prefer? 3.1 or 3.3, in addition or instead of the existing 
2.x (?) references?

> The questions is whether we want to do this now, or once we actually
> support 3.1 or 3.3; what was your intention for preparing this now?

Fallout of some bug fixes I intended to to in the .texi file, which in 
turn was a fallout of the trivial addition of the 3.3 interfaces for 
Fortran. Well, then I realized that 3.1 changed the argument names as well.

I think we should at least do the .texi bug fixes. Additionally, those 
'type, dimension(:[,:]...)' look very odd – thus, I would be inclined to 
do those as well.

Otherwise, it is more the question when to break the keyword= API; 
fortunately, it is not an ABI issue as the compiler just uses it to 
reorder the arguments back to the original declaration.

>> NOTE: Those argument names *do* have an effect and can be a breaking
>> change as Fortran permits using the arg name in the call, e.g.,
>>     call acc_copyin(a=myVar)  ! old
>> must now be called either as
>>     call acc_copyin(data_arg=myVar)  ! new
>> or as
>>     call acc_copyin(myVar)  ! works with old and new names
>> As the latter is way more common, the spec change hopefully does not
>> break too many programs.
> I wonder: would it happen to be possible via "Fortran interface magic" to
> actually support several variants of named arguments?  I agree we can
> drop any bogus GCC-local variants, but is it possible to support all the
> official variants?

Obviously not as the default (Fortran + real world) is to use no 
keywords – and then the two variants become ambiguous. Therefore, 
Fortran doesn't permit to combine two specific functions that only 
differ in this aspect.

If a real-world program uses the keywords by ill chance, it still had 
the very same problem depending on the compiler version and vendor as 
that's an upstream spec change.

The simple solution on the program side is just to drop the keyword – 
then it will work with either variant.

I think only very programs are affected – possibly even none. And I 
wonder how other compilers handle this, given that they also started 
implementing (selected) OpenACC 2.7 and 3.x features (including 3.3, as 
real-world programs proof).

>> And, finally, it synced over all named constants from openacc.f90 to
>> config/accel/openacc.f90.
> I don't think that's necessary: as I understand, that one's for
> 'acc_on_device' only?

I think you are right — unless 'f951' is run on the device side, which 
won't happen for offloading, the accelerator version of the module file 
is not read – only the host version. The named constants will be 
expanded early to their numeric value and only the procedure calls 
remain. — Of those, only 'acc_on_device' has to be available on the 
device side and — hence, it is used at lto/link time by the device-side 
of the linker (by linking libgomp.a).

Thus, I withdraw this change as not being required, not harming, but 
wasting some GCC-build-time (only) file storage size and CPU cycles.

Tobias