From patchwork Fri Mar 29 18:40:21 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tobias Burnus X-Patchwork-Id: 232476 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "localhost", Issuer "www.qmailtoaster.com" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 36E4D2C00BF for ; Sat, 30 Mar 2013 05:40:51 +1100 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; q= dns; s=default; b=mMDvqgSv3HgacHs+oRXfcxJbbxMbu/ICOIHjs43ZTyDSQU Iw7/KT86y7AB8KcMTMXJO16+BCm6wPEAxzIh029ohPro73X+9PkA+oxhBIOIl8nq DgyV3FJamy8S+oYcV0wwAj0yx/pSLAHclzJH75RIcvHDuADl2nYb8wx0TFfX4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:date:from:mime-version:to:subject:content-type; s= default; bh=3BzAm22WGPrTBK6YYnPUsTQBtng=; b=yfXU3nXzd5ejUDeJvEPZ EFTse5Hfvj6tsQLsRcrM2qlJhj1cIZu+ymCSEHrpDkxsMQO72no0b17PKRxRSN9q VlQcJyk3uyHHoExcg5cLKnYbrwocZplQakxE6N5OZOSwZdeLjGIPR6NsosGqRz8f sroBs77PvEegrh8g23H4Obw= Received: (qmail 14352 invoked by alias); 29 Mar 2013 18:40:40 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 14298 invoked by uid 89); 29 Mar 2013 18:40:32 -0000 X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-User: qpsmtpd, 2 recipients Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Fri, 29 Mar 2013 18:40:26 +0000 Received: from archimedes.net-b.de (port-92-195-88-1.dynamic.qsc.de [92.195.88.1]) by mx01.qsc.de (Postfix) with ESMTP id 8CBEC3CAEC; Fri, 29 Mar 2013 19:40:22 +0100 (CET) Message-ID: <5155E015.6010600@net-b.de> Date: Fri, 29 Mar 2013 19:40:21 +0100 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: gcc patches , gfortran Subject: [Fortran, RFC patch] Document naming and argument passing convention X-Virus-Found: No Dear all, the attached patch attempts to document gfortran's naming and argument passing convention when Bind(C) is not used. While Bind(C) is the recommended way for interoperation with other Fortran compilers and other languages, there are situations where this is not possible; for instance, legacy code. Or in case of the MPI standard, the MPI implementation might need this information and MPI performance tool developers (PMPI) have to know how the different Fortran compilers pass the arguments. The attached patch does not (yet) state how array descriptors are handled internally. (I was thinking of deferring this until the new array descriptor becomes available.) I also believe there are other omissions as well and the wording could be improved. Suggestions are welcome. The patch was motivated by Walter's comment** to my VALUE+OPTIONAL patch.* It takes his comments into account and, that part, only reflects gfortran's implementation after the VALUE+OPTIONAL patch has been committed with his suggested change. What do you think? Tobias * http://gcc.gnu.org/ml/fortran/2013-03/msg00102.html ** http://gcc.gnu.org/ml/fortran/2013-03/msg00173.html 2013-01-30 Tobias Burnus PR fortran/54339 * gfortran.texi (Standards): Mention TS29113. (Varying Length Character): Mention deferred-length strings. (Fortran 2003 Status): Add unlimited polymorphic. (TS 29113 Status): Add TYPE(*) and DIMENSION(..). (C Interop): Update the section about TS29113. diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi index eff12d7..c80855c 100644 --- a/gcc/fortran/gfortran.texi +++ b/gcc/fortran/gfortran.texi @@ -522,12 +522,13 @@ ISO/IEC 1539:1997 (Fortran 95). As such, it can also compile essentially all standard-compliant Fortran 90 and Fortran 77 programs. It also supports the ISO/IEC TR-15581 enhancements to allocatable arrays. -In the future, the GNU Fortran compiler will also support ISO/IEC -1539-1:2004 (Fortran 2003), ISO/IEC 1539-1:2010 (Fortran 2008) and -future Fortran standards. Partial support of the Fortran 2003 and -Fortran 2008 standard is already provided; the current status of the -support is reported in the @ref{Fortran 2003 status} and -@ref{Fortran 2008 status} sections of the documentation. +GNU Fortran also have a partial support for ISO/IEC 1539-1:2004 (Fortran +2003), ISO/IEC 1539-1:2010 (Fortran 2008), the Technical Specification +@code{Further Interoperability of Fortran with C} (ISO/IEC TS 29113:2012). +Full support of those standards and future Fortran standards is planned. +The current status of the support is can be found in the +@ref{Fortran 2003 status}, @ref{Fortran 2008 status} and +@ref{TS 29113 status} sections of the documentation. Additionally, the GNU Fortran compilers supports the OpenMP specification (version 3.1, @url{http://openmp.org/@/wp/@/openmp-specifications/}). @@ -545,6 +546,10 @@ for them, which work with GNU Fortran. They can be found at @uref{http://www.fortran.com/@/iso_varying_string.f95} and at @uref{ftp://ftp.nag.co.uk/@/sc22wg5/@/ISO_VARYING_STRING/}. +Deferred-length character strings of Fortran 2003 support part of +the features of @code{ISO_VARYING_STRING} and should be considered as +replacement. (Namely, allocatable or pointers of the type +@code{character(len=:)}.) @c ===================================================================== @@ -807,8 +812,8 @@ operators bound to a type. override type-bound procedures or to have deferred binding. @item Polymorphic entities (``@code{CLASS}'') for derived types -- including -@code{SAME_TYPE_AS}, @code{EXTENDS_TYPE_OF} and @code{SELECT TYPE}. -Note that unlimited polymorphism is currently not supported. +@code{SAME_TYPE_AS}, @code{EXTENDS_TYPE_OF} and @code{SELECT TYPE} for +scalars and arrays, including unlimited polymorphism. @item Generic interface names, which have the same name as derived types, are now supported. This allows one to write constructor functions. Note @@ -1079,16 +1084,23 @@ The @uref{http://gcc.gnu.org/wiki/TS29113Status, wiki} has some information about the current TS 29113 implementation status. In particular, the following is implemented. +See also @ref{Further Interoperability of Fortran with C}. + @itemize @item The @option{-std=f2008ts} option. @item The @code{OPTIONAL} attribute is allowed for dummy arguments of @code{BIND(C) procedures.} -@item The RANK intrinsic is supported. +@item The @code{RANK} intrinsic is supported. @item GNU Fortran's implementation for variables with @code{ASYNCHRONOUS} attribute is compatible with TS 29113. + +@item Assumed types (@code{TYPE(*)}. + +@item Assumed-rank (@code{DIMENSION(..)}). However, the array descriptor +of the TS is not yet supported. @end itemize @@ -2264,7 +2276,7 @@ Derived types with the C binding attribute shall not have the @code{sequence} attribute, type parameters, the @code{extends} attribute, nor type-bound procedures. Every component must be of interoperable type and kind and may not have the @code{pointer} or @code{allocatable} attribute. The names of the -variables are irrelevant for interoperability. +components are irrelevant for interoperability. As there exist no direct Fortran equivalents, neither unions nor structs with bit field or variable-length array members are interoperable. @@ -2304,11 +2316,14 @@ be compatible with C. The dummy argument declaration is relatively straightforward. However, one needs to be careful because C uses call-by-value by default while Fortran behaves usually similar to call-by-reference. Furthermore, strings and pointers are handled -differently. Note that only explicit size and assumed-size arrays are -supported but not assumed-shape or allocatable arrays. +differently. Note that in Fortran 2003 and 2008 only explicit size +and assumed-size arrays are supported but not assumed-shape or +deferred-shape (i.e. allocatable or pointer) arrays. However, those +are allowed since the Technical Specification 29113, see +@ref{Further Interoperability of Fortran with C} To pass a variable by value, use the @code{VALUE} attribute. -Thus the following C prototype +Thus, the following C prototype @smallexample @code{int func(int i, int *j)} @@ -2401,6 +2416,11 @@ The intrinsic procedures are described in @ref{Intrinsic Procedures}. C pointers are represented in Fortran via the special opaque derived type @code{type(c_ptr)} (with private components). Thus one needs to use intrinsic conversion procedures to convert from or to C pointers. + +For some applications, using an assumed type (@code{TYPE(*)}) can be an +alternative to a C pointer; see +@ref{Further Interoperability of Fortran with C}. + For example, @smallexample @@ -2546,17 +2566,76 @@ END MODULE m @node Further Interoperability of Fortran with C @subsection Further Interoperability of Fortran with C -Assumed-shape and allocatable arrays are passed using an array descriptor -(dope vector). The internal structure of the array descriptor used -by GNU Fortran is not yet documented and will change. There will also be -a Technical Specification (TS 29113) which standardizes an interoperable -array descriptor. Until then, you can use the Chasm Language +The Technical Specicification ISO/IEC TS 29113:2012 on further +interoperability of Fortran with C extends the interoperability support +of Fortran 2003 and Fortran 2008. Besides removing some restrictions +and constraints, it adds assumed-type (@code{TYPE(*)}) and assumed-rank +(@code{dimension}) variables and allows for interoperability of +assumed-shape, assumed-rank and deferred-shape arrays, including +allocatables and pointers. + +Note: Currently, GNU Fortran does not support the array descriptor +(dope vector) as specified in the Technical Specification, but uses +an array descriptor with different fields. The Chasm Language Interoperability Tools, @url{http://chasm-interop.sourceforge.net/}, -which provide an interface to GNU Fortran's array descriptor. +provide an interface to GNU Fortran's array descriptor. + +The Technical Specification adds the following new features, which +are supported by GNU Fortran: -GNU Fortran already supports the C-interoperable @code{OPTIONAL} -attribute; for absent arguments, a @code{NULL} pointer is passed. +@itemize @bullet +@item The @code{ASYNCHRONOUS} attribute has been clarified and +extended to allow its use with asynchronous communication in +user-provided libraries such as in implementations of the +Message Passing Interface specification. + +@item Many constraints have been relaxed, in particular for +the @code{C_LOC} and @code{C_F_POINTER} intrinsics. + +@item The @code{OPTIONAL} attribute is now allowed for dummy +arguments; an absent argument matches a @code{NULL} pointer. + +@item Assumed types (@code{TYPE(*)}) have been added, which may +only be used for dummy arguments. They are unlimited polymorphic +but contrary to @code{CLASS(*)} they do not contain any type +information, similar to C's @code{void *} pointers. Expressions +of any type and kind can be passed; thus, it can be used as +replacement for @code{TYPE(C_PTR)}, avoiding the use of +@code{C_LOC} in the caller. + +Note, however, that @code{TYPE(*)} only accepts scalar arguments, +unless the @code{DIMENSION} is explicitly specified. As +@code{DIMENSION(*)} only supports array (including array elements) but +no scalars, it is not a full replacement for @code{TYPE(C_PTR)}. On the +other hand, assumed-type assumed-rank dummy arguments +(@code{TYPE(*), DIMENSION(..)}) allow for both scalars and arrays, but +require special code on the callee side to handle the array descriptor. + +@item Assumed-shape arrays (@code{DIMENSION(..)}) as dummy argument +allow that scalars and arrays of any rank can be passed as actual +argument. As the Technical Specification does not provide for direct +means to operate with them, they have to be used either from the C side +or be converted using @code{C_LOC} and @code{C_F_POINTER} to scalars +or arrays of a specific rank. The rank can be determined using the +@code{RANK} intrinisic. +@end itemize + + +Currently unimplemented: + +@itemize @bullet + +@item GNU Fortran always uses an array descriptor, which does not +match the one of the Technical Specification. The +@code{ISO_Fortran_binding.h} header file and the C functions it +specifies are not available. + +@item Using assumed-shape, assumed-rank and deferred-shape arrays in +@code{BIND(C)} procedures is not fully supported. In particular, +C interoperable strings of other length than one are not supported +as this requires the new array descriptor. +@end itemize @node GNU Fortran Compiler Directives