Re: [PATCH] OpenACC routines in fortran modules

[Cesar Philippidis <cesar@codesourcery.com>]

On 07/28/2016 02:55 AM, Tobias Burnus wrote:
> Cesar Philippidis wrote:
>> It turns out that the acc routine parallelism isn't being recorded in
>> fortran .mod files. This is a problem because then the ME can't validate
>> if a routine has compatible parallelism with the call site. 
> 
> Nothing against saving such information in .mod files. However, I wonder
> whether it can happen that one places such an 'acc routine' outside of a
> module in one file - and still accesses it from another file. In the simple
> non-ACC case, one can have:
> 
> !----- one.f90 ----
> subroutine foo()
>   print *, "abc"
> end subroutine foo
> 
> !---- two.f90 ---
> program example
>   call foo()
> end program example
> 
> where "foo()" is torn in without any information about it (except that it
> is a subroutine, does not require an explicit interface, and takes no
> arguments).
> 
> I don't know whether the ACC spec requires an explicit interface in that
> case (i.e. for acc routines); I bet it does - or at least should. In that

Jakub and I discussed this issue a while ago. There were two major
problems with treating calls to non-acc routines as errors. 1) What do
we do about intrinsic procedures, and 2) how should builtin and
libc/libm functions get handled? Jakub and I came to the conclusion that
the linker should resolve those issues, hence this patch
<https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00043.html> which teaches
the lto wrapper to error when it encounters missing symbols. From a
compiler standpoint, if the user does something like this

!$acc parallel
...
call foo()
...
!$acc end parallel

and if foo isn't marked as an acc routine, then the compiler will treat
that function as having an implicit 'acc routine seq'.

Note that trunk currently generates an error if the user tries apply an
acc routine directive on an intrinsic routine. This patch teaches
gfortran to accept acc routine directives on those procedures. However,
note that those routines aren't automatically parallelized though, i.e.
they are effectively implemented as 'acc routine seq'.

> case, something like the following would be valid - and should be supported
> as well. (I don't know whether it currently is.)
>
> !----- one.f90 ----
> subroutine foo()
>   !$acc routine gang
>   .... ! something
> end subroutine foo
> 
> !---- two.f90 ---
> program example
>   INTERFACE
>     subroutine foo()
>       !$acc routine gang
>       ! Nothing here
>     end subroutine foo
>   END INTERFACE
> 
>   call foo()
> end program example
> 
> Namely, a replication of the declaration of the procedure, including
> the "acc routine", in the 'interface'.
> (If one concats the two files, I would also expect an error with -fopenacc,
> if the "acc routine" doesn't match between "foo" and the "foo" in the
> "interface" block.)

I tested this case and it works. There is, however, a problem with
mismatched routine clauses. See PR72741 that Thomas filed recently.

> Otherwise: Have you checked whether an unmodified gfortran still accepts the
> .mod file written by the patched gfortran - and vice versa? Especially if
> -fopenacc is not used, backward compatibility of .mod files is a goal.
> (Even though we often have to bump the .mod version for major releases.)

I just tested this situation, and neither backward or forward compatible
isn't preserved. Basically, this patch introduces a mandatory
OACC_FUNCTION_ field inside the module file. Perhaps I should make that
field optional. At least that way we'd maintain backwards compatibility.
Is there something I can do to maintain forward compatibility?

Cesar