Hi Thomas,
(Regarding 'call acc_attach(x)' – the problem is that one needs the
address of '&x' and 'x'; while 'x' is readily available, for '&x' no
temporary variable has to get involved – and there are plenty of ways
temporaries can get introduced; for most cases, an interface exists that
prevents this but they are mutually exclusive. Hence, this needs support
in the FE. The simplest workaround for a user is to use '!$acc attach'
instead ...)
Thomas Schwinge:
@table @asis
@item @emph{Description}
-This function allocates @var{len} bytes of device memory. It returns
+This function allocates @var{bytes} of device memory. It returns
Not '@var{bytes} {+bytes+}' or similar?
I think either works – depending how one parses @var{<name>} mentally,
one of the variants sounds smooth and the other very odd. But I can/will
change it.
--- a/libgomp/openacc.f90
+++ b/libgomp/openacc.f90
Assuming that 'module openacc_internal' currently is sorted per
appearance in the OpenACC specification (?), I suggest we continue to do
so. (..., like in 'openacc_lib.h', too.)
I will check – it looks only block-wise sorted but I might be wrong.I
followed location of the comments, placing it before the routines that
followed the comment, assuming that the comments were at the right spot.
@@ -794,6 +881,9 @@ module openacc
...
+ public :: acc_malloc, acc_free, acc_map_data, acc_unmap_data, acc_deviceptr
+ public :: acc_hostptr, acc_memcpy_to_device, acc_memcpy_to_device_async
+ public :: acc_memcpy_from_device, acc_memcpy_from_device_async
...
- ! acc_malloc: Only available in C/C++
- ! acc_free: Only available in C/C++
-
...
interface acc_is_present
procedure :: acc_is_present_32_h
procedure :: acc_is_present_64_h
procedure :: acc_is_present_array_h
end interface
Is that now a different style that we're not listing the new interfaces
in 'module openacc' here?
As there is no precedent for this type of interface, the style is by
nature differently. But the question is which style is better. The
current 'openacc' is very short – and contains not a single specific
interface, but only generic interfaces. The actual specific-procedure
declarations are only in 'openacc_internal'.
Those new procedures are the first ones that do not have a generic
interface and only a specific one. Thus, one can either put the specific
one into 'openacc_internal' and refer it from 'openacc' (via 'use
openacc_internal' + 'public :: acc_<routine-name>') – or place the
interface directly into 'openacc' (and not touching 'openacc_internal'
at all).
During development, I had a accidentally a mixture between both - and
then settled for the current variant. – Possibly, moving the interface
to 'openacc' is clearer?
Thoughts?
--- /dev/null
+++ b/libgomp/testsuite/libgomp.fortran/acc_host_device_ptr.f90
[...]
+! Fortran version of libgomp.oacc-c-c++-common/lib-59.c
I like to also put a cross reference into the originating C/C++ test
case, so that anyone adjusting either one also is aware that another one
may need adjusting, too.
OK - I will do so.
+ ! The following assumes sizeof(void*) being the same on host and device:
That's generally required anyway.
I have to admit that I don't know OpenACC well enough to see whether
that's the case or not. And, while I am not very consistent, I do try to
document stricter requirements / implementation-specific parts in a
testcases.
I know that OpenMP permits that the pointer size differs and 'void *p =
omp_target_alloc (...);' might in this case not return the device
pointer but a handle to the device ptr. (For instance, it could be a
pointer to an uint128_t variable for a 128bit device pointer; I think
such a hardware exists in real - and uses several bits for other
purposes like flags.)
In that case, host-side pointer arithmetic won't work and
'is_device_ptr' clauses etc. need to do transfer work.
But, admittedly, in GCC there it is assumed at many places that both
sides use the same pointer size* and also during specification
development, everyone implicitly assumes that routines and clauses yield
bare device pointers and not some opaque pointer to the actual data (a
handle); hence, one has to keep remind oneself that the spec permits
system where that's not the case.
Tobias
(* There are a few spots which handle a smaller device pointer than the
host pointer or consider a different size but that's not done very
consistently and largely lacking.)
