On 18/07/2019 10:28 am, Tobias Burnus wrote:
Hi all,
I played around and came up with another second way one gets a single "*"
without
'optional'.
I haven't checked whether which of those match the proposed
omp_is_optional_argument's
+ && DECL_BY_REFERENCE (decl)
+ && TREE_CODE (TREE_TYPE (decl)) == POINTER_TYPE;
nor whether some checks reject any of those with OpenACC (or OpenMP).
In any case, the dump of "type(c_ptr),value", "integer, dimension(1)" and
"integer,optional"
is:
static void foo (void *, integer(kind=4)[1] *, integer(kind=4) *);
The case of the fixed-length array currently doesn't work properly with
omp_is_optional_argument, as it returns true whether or not it is optional.
Indeed, the PARM_DECL doesn't seem to change between optional and non-optional,
so it is probably impossible to discern via the tree unless some extra
information is added by the front-end.
However, optional arrays still 'just work' with my patches (most of the
testcases include tests for arrays in optional arguments). I believe this is
because the existing code must already deal with pointers to arrays, so the
false positive simply does not matter on the codepath taken. The new case of a
null pointer (in the case of a non-present optional argument) was dealt with by
making operations on null pointers into NOPs.
Actually, if one combines VALUE with OPTIONAL, it gets even more interesting.
To implement it, one has two choices:
* pass a copy by reference (or NULL)
* pass by value (including a dummy value if absent) and denote the state as
extra argument.
The latter is done in gfortran, cf. PR fortran/35203, following the IBM
compiler.
I am not sure whether it does need special care fore OpenACC (or OpenMP 5)
offloading,
but that's at least a case which is not handled by the patch.
Optional by-value arguments are tested in optional-data-copyin-by-value.f90.
They do not need extra handling, since from the OACC lowering perspective they
are just two bog-standard integral values of no special interest.
Kwok
