Hi Thomas,
Thomas Schwinge wrote:
On 2024-02-27T20:11:30+0100, Tobias Burnus<tbur...@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
