Next set of OpenACC changes: Fortran

[James Norris]

Tobias,

First, thank you for taking the time to review the patch.
Second, thank you for providing the comments. It appears
all of the comments need to be acted upon in some manner.

Thanks!


On 05/05/2015 05:01 AM, Tobias Burnus wrote:
> Thomas Schwinge wrote:
>> In follow-up messages, I'll be posting the separated parts (for easier
>> review) of a next set of OpenACC changes that we'd like to commit.
>> ChangeLog updates not yet written; will do that before commit, obviously.
> Still, it would have been nice if you had given an overview about what
> the main part of the patch does. In this case, there is neither some intro
> words nor a ChangeLog (which also gives an overview what the patch does).
>
> Regarding the !$ACC ROUTINE support, which the patch adds: In my very
> rough understanding, the compiler has to know at compile time whether a
> procedure is a '!$ACC ROUTINE' or not. Thus, it should work if you declare
> in one file:
>
> !--------- file1.f90-----------
> subroutine foo()
>    !$acc routine
> end subroutine foo
> !--- end of file
>
> and invoke it in a different file:
>    call foo()
>
> In order that this works in Fortran, you need to support two ways of
> handling this information:
>
>
> a) modules:
>
> module m
> contains
>    subroutine foo()
>      !$acc routine
>    end subroutine foo
> end module m
>
> Thus, I had expected that you store this information (at least the relevant
> parts) in the .mod file. (-> fortran/module.c)
>
>
> b) interfaces, i.e. in the scope of the caller:
>
> interface
>    subroutine foo()
>      !$acc routine
>    end subroutine foo
> end interface
>
> !$acc parallel
> ...
> call foo()
> ...
> !$acc end parallel
>
>
> Semantically, something like the the latter is also needed in the same file
> if the procedure "foo" is stand along (i.e. neither in a module nor 'contained'
> (internal procedure) of the caller nor a sibling internal procedure of the
> caller). However, as the original declaration is available, supporting (b) is
> only semantical sugar - especially a check whether the !$acc routine is provided
> in the interface and matches the original declaration.
>
>
> Thus, can you check:
> * whether you need to store information in the .mod file?
> * whether (b) is/should be supported? (And with how much error diagnostic
>    in case of the same TU and mismatches.)
> And, if needed, provide some test cases?
>
> And if you are there:
> * Whether something similar to .mod has to be done for LTO?
> * Could you also create a test case, where Fortran calls C or vice versa for
>    an OpenACC ROUTINE?
>
> Tobias