From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31138 invoked by alias); 14 Nov 2014 20:47:24 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 31121 invoked by uid 89); 14 Nov 2014 20:47:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx02.qsc.de Received: from mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 14 Nov 2014 20:47:22 +0000 Received: from tux.net-b.de (port-92-194-240-118.dynamic.qsc.de [92.194.240.118]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx02.qsc.de (Postfix) with ESMTPSA id 60B7827658; Fri, 14 Nov 2014 21:47:18 +0100 (CET) Message-ID: <54666A55.4060408@net-b.de> Date: Fri, 14 Nov 2014 21:01:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Thomas Schwinge , Jakub Jelinek , fortran@gcc.gnu.org CC: gcc-patches@gcc.gnu.org, Julian Brown Subject: Re: Fortran/C interfacing References: <20140923191931.2177e60f@octopus> <20141111135323.29e0f27b@octopus> <20141112100626.GP5026@tucnak.redhat.com> <20141113232615.4ff373bf@octopus> <87sihlbwt7.fsf@kepler.schwinge.homeip.net> In-Reply-To: <87sihlbwt7.fsf@kepler.schwinge.homeip.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2014-11/txt/msg01893.txt.bz2 Am 14.11.2014 um 16:56 schrieb Thomas Schwinge: > Hi! > > On Wed, 12 Nov 2014 11:06:26 +0100, Jakub Jelinek wrote: >> On Tue, Nov 11, 2014 at 01:53:23PM +0000, Julian Brown wrote: >>> [OpenACC libgomp changes][openacc.f90, and exporting symbols in libgomp.map] >>> >>> >> Somebody recently suggested (for OpenMP) that we just should use >> bind(C) in the Fortran module, it is too late for OpenMP, as we >> have to keep the *_ entrypoints for compatibility anyway, but >> for OpenACC and new OpenMP functions supposedly you could avoid >> exporting all the *_ wrappers and use * directly. > Tobis, as our local expert :-) -- how does that "resonate" with the > discussion (and implementation) about Fortran/C interfacing Unfortunately, it a wrapper either on C or on Fortran side is unavoidable. For C/C++, one has has: void* acc_copyin(h_void*, size_t ); That matches (if one ignores the return type): subroutine acc_copyin(a, len) bind(C) use iso_c_binding, only: c_size_t type(*) :: a integer(c_size_t) :: len If one looks at Fortran's first interface, it seems to match: subroutine acc_copyin(a, len ) type:: a integer :: len However, a default-size integer in Fortran is usually* 4-bytes wide while size_t on most 64bit systems** is 8-bytes wide. As Fortran doesn't automatically convert the integer type, I think there is no way but providing additionally a function which takes an "int"/default-kind integer. (* unless one uses -fdefault-integer-8; ** such as x32.) I think in the current version of the patch – I haven't re-checked –, one provides both a function for int32 and int64, one matching a 32 and one a 64 bit integer. Additionally, it permits to use >2GB arrays. In principle, one of the versions could directly invoke the C function without the wrapper [where c_size_t == kind(integer)] - but that would require come conditional compilation. Whether one has a trailing "_" and whether one implements it in C or in Fortran doesn't really matter. The second Fortran interface is: subroutine acc_copyin(a) type, dimension(: [,:]…) :: a which can be best writtin in modern Fortran as: class(*), dimension(..) :: a and which, knowing the internal implementation, I wrote as type(*), dimension(..) :: a as it avoids some extra code on the caller side - but it is not fully standard conform. On the other hand, "type(*), dimension(..)" can be also marked as BIND(C). There is no C equivalent but one can use something like call acc_copyin(c_loc(a), size(a)*storage_size(a)/8) to convert it to the C form of the function. Again, this conversion can be done either in Fortran or in C. One just needs to take the first field of the array descriptor - the address of the actual data - and needs to extract the size of an element and the number of elements. (Caveat: The current code only works if the array is contiguous and the argument is not an assumed-size array.) Thus, all in all, I think the current implementation is okay. However, if someone has a better suggestion, I am interested. Tobias PS: I am happy that TYPE(*) and DIMENSION(..) exist (both in the standard and in the compiler) as they make life much simpler. Otherwise, providing an explicit interface would be tediuous for intrinsic types and impossible for derived types.