From owner-sc22wg5@open-std.org Thu Dec 18 08:17:09 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 7E8A5C56CF8; Thu, 18 Dec 2008 08:17:09 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from sca-es-mail-1.sun.com (sca-es-mail-1.Sun.COM [192.18.43.132]) by www2.open-std.org (Postfix) with ESMTP id 3FAFEC178DE for ; Thu, 18 Dec 2008 08:17:07 +0100 (CET) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id mBI7Gtmm006797 for ; Wed, 17 Dec 2008 23:17:06 -0800 (PST) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0KC200H019HXOI00@fe-sfbay-09.sun.com> (original mail from Robert.Corbett@Sun.COM) for sc22wg5@open-std.org; Wed, 17 Dec 2008 23:16:55 -0800 (PST) Received: from [129.146.84.104] by fe-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0KC20000X9K6OK70@fe-sfbay-09.sun.com>; Wed, 17 Dec 2008 23:16:55 -0800 (PST) Date: Wed, 17 Dec 2008 23:16:54 -0800 From: Robert Corbett Subject: Re: (j3.2006) (SC22WG5.3823) Please tell me I'm wrong In-reply-to: <20081217154456.1CF96C178D6@www2.open-std.org> To: fortran standards email list for J3 Cc: MPI-3 Fortran working group , WG5 Reply-To: Robert.Corbett@Sun.COM Message-id: <4949F8E6.9030708@sun.com> Organization: Sun Microsystems, Inc. MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=us-ascii Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en References: <20081217154456.1CF96C178D6@www2.open-std.org> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Sender: owner-sc22wg5@open-std.org Precedence: bulk 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