[MPI3 Fortran] (j3.2006) (SC22WG5.3823) Please tell me I'm wrong

[Robert Corbett]

Craig Rasmussen wrote:
> Without help from the Fortran standard, I don't think there is anyway to 
> avoid a combinatorial explosion of interfaces (made worse by the F2008 
> with 15 dimensions).  Consider the simple example code snippet:
> 
> ---------
> 
> subroutine test_recv(message)
>  real :: message(:,:)
> 
>  call MPI_Recv(message, 2, MPI_INTEGER, 1, 1, MPI_COMM_WORLD, 
> MPI_STATUS_IGNORE)
> 
> end subroutine
> 
> ---------
> 
> For interface declaration:
> 
> subroutine MPI_Recv_wrapper(buf, count, datatype, source, tag, comm, 
> status, err)
>  real, dimension(*), intent(out)  :: buf
> 
> or:
> 
> subroutine MPI_Recv_wrapper(buf, count, datatype, source, tag, comm, 
> status, err)
>  real, dimension(1,1,1,1,1,1,*), intent(out)  :: buf
> 
> This give the following error with the Intel compiler:
> 
> fortcom: Error: test_recv_call.f90, line 15: There is no matching 
> specific subroutine for this generic subroutine call.   [MPI_RECV]
>  call MPI_Recv(message, 2, MPI_INTEGER, dest, 1, MPI_COMM_WORLD, 
> MPI_STATUS_IGNORE)
> --------^
> 
> On the other hand, if we use the interface:
> 
> subroutine MPI_Recv_wrapper(buf, count, datatype, source, tag, comm, 
> status, err)
>  type(C_PTR) :: buf
> 
> There is still a problem as assumed shape arrays are not interoperable. 
>  From gfortran:
> 
>  call MPI_Recv(C_LOC(message), 2, MPI_INTEGER, dest, 1, MPI_COMM_WORLD, requ
>                                           1
> Error: Assumed-shape array 'message' at (1) cannot be an argument to the 
> procedure 'c_loc because it is not C interoperable
> 
> 
> So there doesn't seem to be anyway to currently do multi-dimensional 
> interfaces for assumed-shape actuals without a combinatorial explosion 
> of interfaces.  This also seems to be the case for assumed-size actuals 
> as well.
> 
> Comments?

I have given some consideration to the final point.  The restriction
that C_LOC cannot be applied to an array that is not contiguous seems
to be unnecessary for most types on most architectures.  I am not sure
if it csn work for arrays of type CHARACTER on machines where the
smallest addressable unit is larger than a byte, but other than that,
I see no need for the restriction.

If C_LOC is extended to allow actual arguments that are not contiguous,
one further extension is needed to make it useful, namely, a way to
access the strides.  The intrinsic function SHAPE provides an array of
the extents of the array.  A function, say C_STRIDE, could provide an
array of strides.

Given those two extensions, a C function could be written to access the
elements of an assumed-shape or deferred-shape array.  The form of the
prototype for the function might be

     foo(int rank, void* address, size_t extent[restrict],
         ptrdiff_t stride[restrict], ...)

Bob Corbett