From owner-sc22wg5@open-std.org Wed Dec 17 17:56:28 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id BF8CAC178DE; Wed, 17 Dec 2008 17:56:28 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from e8.ny.us.ibm.com (e8.ny.us.ibm.com [32.97.182.138]) by www2.open-std.org (Postfix) with ESMTP id D3611C178D6 for ; Wed, 17 Dec 2008 17:56:26 +0100 (CET) Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.13.1/8.13.1) with ESMTP id mBHGpMpE022007 for ; Wed, 17 Dec 2008 11:51:22 -0500 Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id mBHGuMoE183914 for ; Wed, 17 Dec 2008 11:56:23 -0500 Received: from d01av05.pok.ibm.com (loopback [127.0.0.1]) by d01av05.pok.ibm.com (8.13.1/8.13.3) with ESMTP id mBHGuMH3002457 for ; Wed, 17 Dec 2008 11:56:22 -0500 Received: from d25ml04.torolab.ibm.com (d25ml04.torolab.ibm.com [9.26.6.105]) by d01av05.pok.ibm.com (8.13.1/8.12.11) with ESMTP id mBHGuMhn002450; Wed, 17 Dec 2008 11:56:22 -0500 In-Reply-To: <20081217154456.1CF96C178D6@www2.open-std.org> References: <20081217154456.1CF96C178D6@www2.open-std.org> To: fortran standards email list for J3 Cc: MPI-3 Fortran working group , WG5 MIME-Version: 1.0 Subject: Re: (j3.2006) (SC22WG5.3823) Please tell me I'm wrong X-Mailer: Lotus Notes Release 8.0.1 HF105 April 10, 2008 Message-ID: From: Jim Xia Date: Wed, 17 Dec 2008 11:56:20 -0500 X-MIMETrack: Serialize by Router on D25ML04/25/M/IBM(Release 7.0.3FP1|February 24, 2008) at 12/17/2008 11:56:22, Serialize complete at 12/17/2008 11:56:22 Content-Type: multipart/alternative; boundary="=_alternative 005D0BAE85257522_=" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. --=_alternative 005D0BAE85257522_= Content-Type: text/plain; charset="US-ASCII" Craig If your message is a contiguous assumed-shape, then you can solve the problem without Fortran committee's help by using a conversion function as follows function convertToRank1 (x, n) result (res) real, target, intent(inout) :: x(n) integer, intent(in) :: n real, pointer :: res(:) res => x end function The your subroutine can be rewritten as follows subroutine test_recv (message) real, target :: message(:,:) !<-- assume it is contiguous real, pointer :: remappedArray(:) remappedArray => convertToRank1(message, size(message)) call MP_Recv (remappedArray, 2, MPI_INTEGER, 1, 1, MPI_COMM_WORLD, MPI_STATUS_IGNORE) end subroutine That only solves the problem if the assumed-shape is contiguous. In F03 we have bounds-remapping for pointers that converts (maps) rank one target to multi-dimension arrays. I think that can be used if your test_recv() always expects a rank-one array assumed-shape dummy. You can map that array into a rank-n array using data pointer assignment to match the interface of MPI_Recv_wrapper, then you don't have the problems with generic resolution issues. Cheers, Jim Xia RL Fortran Compiler Test IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7 Phone (905) 413-3444 Tie-line 313-3444 email: jimxia@ca.ibm.com D2/YF7/8200 /MKM From: Craig Rasmussen To: MPI-3 Fortran working group Cc: WG5 Date: 12/17/2008 10:45 AM Subject: (j3.2006) (SC22WG5.3823) Please tell me I'm wrong 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? Cheers, Craig _______________________________________________ J3 mailing list J3@j3-fortran.org http://j3-fortran.org/mailman/listinfo/j3 --=_alternative 005D0BAE85257522_= Content-Type: text/html; charset="US-ASCII"
Craig

If your message is a contiguous assumed-shape, then you can solve the problem without Fortran committee's help by using a conversion function as follows

function convertToRank1 (x, n) result (res)
   real, target, intent(inout) :: x(n)
   integer, intent(in) :: n

   real, pointer :: res(:)

   res => x
end function

The your subroutine can be rewritten as follows

subroutine test_recv (message)
    real, target :: message(:,:)  !<-- assume it is contiguous

    real, pointer :: remappedArray(:)

   remappedArray => convertToRank1(message, size(message))

   call MP_Recv (remappedArray, 2, MPI_INTEGER, 1, 1, MPI_COMM_WORLD, MPI_STATUS_IGNORE)

end subroutine


That only solves the problem if the assumed-shape is contiguous.  In F03 we have bounds-remapping for pointers that converts (maps) rank one target to multi-dimension arrays.  I think that can be used if your test_recv() always expects a rank-one array assumed-shape dummy. You can map that array into a rank-n array using data pointer assignment to match the interface of MPI_Recv_wrapper, then you don't have the problems with generic resolution issues.


Cheers,

Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia@ca.ibm.com
D2/YF7/8200 /MKM


From: Craig Rasmussen <crasmussen@lanl.gov>
To: MPI-3 Fortran working group <mpi3-fortran@lists.mpi-forum.org>
Cc: WG5 <sc22wg5@open-std.org>
Date: 12/17/2008 10:45 AM
Subject: (j3.2006) (SC22WG5.3823) Please tell me I'm wrong




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?

Cheers,
Craig

_______________________________________________
J3 mailing list
J3@j3-fortran.org
http://j3-fortran.org/mailman/listinfo/j3

--=_alternative 005D0BAE85257522_=--