This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 2/5, OpenACC] Support Fortran optional arguments in the firstprivate clause


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]