Implementing OpenACC's Fortran module

[Thomas Schwinge]

Hi Jakub!

On Tue, 23 May 2017 13:12:00 +0200, Jakub Jelinek <jakub@redhat.com> wrote:
> On Mon, May 22, 2017 at 05:23:25PM +0200, Thomas Schwinge wrote:
> > --- libgomp/openacc_lib.h
> > +++ libgomp/openacc_lib.h
> > @@ -191,23 +191,9 @@
> >        end interface
> >  
> >        interface acc_pcopyin
> > -        subroutine acc_pcopyin_32_h (a, len)
> > -          use iso_c_binding, only: c_int32_t
> > -          !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
> > -          type (*), dimension (*) :: a
> > -          integer (c_int32_t) len
> > -        end subroutine
> > -
> > -        subroutine acc_pcopyin_64_h (a, len)
> > -          use iso_c_binding, only: c_int64_t
> > -          !GCC$ ATTRIBUTES NO_ARG_CHECK :: a
> > -          type (*), dimension (*) :: a
> > -          integer (c_int64_t) len
> > -        end subroutine
> > -
> > -        subroutine acc_pcopyin_array_h (a)
> > -          type (*), dimension (..), contiguous :: a
> > -          end subroutine
> > +        procedure :: acc_present_or_copyin_32_h
> > +        procedure :: acc_present_or_copyin_64_h
> > +        procedure :: acc_present_or_copyin_array_h
> >        end interface
> 
> My Fortran knowledge is limited

Same here.  ;-)

> does this actually provide
> the interfaces of those procedures (what arguments they have
> and other their properties)

This ("procedure" instead of "subroutine") is actually what "openacc.f90"
is using in the same context, and upon having inspected (already back in
April) the "-fdump-fortran-original" output for the new
"libgomp.oacc-fortran/lib-32-1.f" test case, this seemed to do the right
things.  And, comparing that to the "openacc.f90" case
("libgomp.oacc-fortran/lib-32-2.f" test case with "USE OPENACC"), the
only difference in "-fdump-fortran-original" output relevant to this
issue here are (expected) additional "USE-ASSOC(openacc)" attributes.

> or shall it instead use
> subroutine acc_present_or_copyin_32_h (a, len)
>   ...
> end subroutine
> etc. there?

Apparently not.  These "subroutine"s have already declared above (for
"acc_present_or_copyin" proper), and if declaring them again here, we
get:

    Error: Symbol 'acc_present_or_copyin_32_h' at (1) already has an explicit interface
    [...]


Thus OK for trunk, as posted?


Grüße
 Thomas