From owner-sc22wg5@open-std.org  Wed Dec 17 20:40:07 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 17FDDC56CF8; Wed, 17 Dec 2008 20:40:07 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
X-Greylist: delayed 323 seconds by postgrey-1.18 at www2.open-std.org; Wed, 17 Dec 2008 20:40:05 CET
Received: from proofpoint2.lanl.gov (proofpoint2.lanl.gov [204.121.3.26])
	by www2.open-std.org (Postfix) with ESMTP id F2E4CC178DE
	for <sc22wg5@open-std.org>; Wed, 17 Dec 2008 20:40:05 +0100 (CET)
Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103])
	by proofpoint2.lanl.gov (8.13.8/8.13.8) with ESMTP id mBHJYUM7029707;
	Wed, 17 Dec 2008 12:34:30 -0700
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mailrelay2.lanl.gov (Postfix) with ESMTP id C00D315D9E23;
	Wed, 17 Dec 2008 12:34:30 -0700 (MST)
X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov
Received: from webmail1.lanl.gov (webmail1.lanl.gov [128.165.4.106])
	by mailrelay2.lanl.gov (Postfix) with ESMTP id A1CAB15D9E21;
	Wed, 17 Dec 2008 12:34:30 -0700 (MST)
Received: by webmail1.lanl.gov (Postfix, from userid 48)
	id 9F9A41518033; Wed, 17 Dec 2008 12:34:30 -0700 (MST)
Received: from 128.165.0.81
        (SquirrelMail authenticated user 146526)
        by webmail.lanl.gov with HTTP;
        Wed, 17 Dec 2008 12:34:30 -0700 (MST)
Message-ID: <21064.128.165.0.81.1229542470.squirrel@webmail.lanl.gov>
In-Reply-To: 
     <OF28EAD298.DC54925C-ON85257522.005B0681-85257522.005D0BB0@ca.ibm.com>
References: <20081217154456.1CF96C178D6@www2.open-std.org>
    <OF28EAD298.DC54925C-ON85257522.005B0681-85257522.005D0BB0@ca.ibm.com>
Date: Wed, 17 Dec 2008 12:34:30 -0700 (MST)
Subject: Re: (j3.2006) (SC22WG5.3823) Please tell me I'm wrong
From: "Craig E. Rasmussen" <rasmussn@lanl.gov>
To: "fortran standards email list for J3" <j3@j3-fortran.org>
Cc: "fortran standards email list for J3" <j3@j3-fortran.org>,
	"WG5" <sc22wg5@open-std.org>,
	"MPI-3 Fortran working group" <mpi3-fortran@lists.mpi-forum.org>
Reply-To: rasmussn@lanl.gov
User-Agent: SquirrelMail/1.4.8-4.0.1.el5.lanl.4
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Proofpoint-Virus-Version: vendor=fsecure engine=4.65.7400:2.4.4,1.2.40,4.0.164 definitions=2008-12-17_15:2008-12-17,2008-12-17,2008-12-17 signatures=0
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Jim,

Thanks for your response.  The question was not really how to get around
the problem but to ask why the problem exists in the first place.  MPI
users have been using generic MPI interfaces for years (using F77 style
implicit interfaces) so they won't be happy if they have to change their
codes in this way.

I think I have figured out the reasoning.  I can argument associate a 2D
array with a 1D dummy specified as

    real :: dimension(*) :: dummy_array

However, generic resolution can't be used to resolve a procedure calling
with a 2D actual to a 1D dummy.

Is this reasoning correct?

Thanks,
Craig



> 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
>
>
> _______________________________________________
> J3 mailing list
> J3@j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>

