From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue May 28 21:50:28 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id CF34B356E50; Tue, 28 May 2013 21:50:28 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 360 seconds by postgrey-1.34 at www5.open-std.org; Tue, 28 May 2013 21:50:28 CEST Received: from postout2.mail.lrz.de (postout2.mail.lrz.de [129.187.255.138]) by www.open-std.org (Postfix) with ESMTP id 61636356929 for ; Tue, 28 May 2013 21:50:14 +0200 (CEST) Received: from lxmhs52.srv.lrz.de (localhost [127.0.0.1]) by postout2.mail.lrz.de (Postfix) with ESMTP id 3bKlqc5gF2zyRw; Tue, 28 May 2013 21:44:12 +0200 (CEST) X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs52.srv.lrz.de Received: from postout2.mail.lrz.de ([127.0.0.1]) by lxmhs52.srv.lrz.de (lxmhs52.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id AoQ-7HL3pq3v; Tue, 28 May 2013 21:44:11 +0200 (CEST) Received: from BADWLRZ-SWHBT2.ads.mwn.de (BADWLRZ-SWHBT2.ads.mwn.de [IPv6:2001:4ca0:0:108::126]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "BADWLRZ-SWHBT2", Issuer "BADWLRZ-SWHBT2" (not verified)) by postout2.mail.lrz.de (Postfix) with ESMTPS id 3bKlqb3J0XzyRW; Tue, 28 May 2013 21:44:11 +0200 (CEST) Received: from BADWLRZ-SWMBX11.ads.mwn.de ([fe80::6de5:ff8b:1900:b1a1]) by BADWLRZ-SWHBT2.ads.mwn.de ([fe80::5951:9dc3:7b2b:14ba%13]) with mapi id 14.03.0123.003; Tue, 28 May 2013 21:43:41 +0200 From: "Bader, Reinhold" To: "longb@cray.com" , sc22wg5 Subject: AW: (SC22WG5.5004) (j3.2006) AW: Corrections to TS29113 Thread-Topic: (SC22WG5.5004) (j3.2006) AW: Corrections to TS29113 Thread-Index: AQHOW8yaKKmY+RKywEW4kYJmlGREc5ka8yZQ Date: Tue, 28 May 2013 19:43:40 +0000 Message-ID: <166ED263DF83324D9A3BA67FB6772B2B59FA037F@BADWLRZ-SWMBX11.ads.mwn.de> References: <20130527194800.755D0356E40@www.open-std.org> <20130528064313.2D3EA356EC9@www.open-std.org> <20130528175553.29F77356E2E@www.open-std.org> In-Reply-To: <20130528175553.29F77356E2E@www.open-std.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4ca0:0:f031::3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-sc22wg5@open-std.org Precedence: bulk Hello Bill,=20 > -----Urspr=FCngliche Nachricht----- > Von: owner-sc22wg5@open-std.org [mailto:owner-sc22wg5@open-std.org] Im > Auftrag von Bill Long > Gesendet: Dienstag, 28. Mai 2013 19:56 > An: sc22wg5 > Betreff: (SC22WG5.5004) (j3.2006) AW: Corrections to TS29113 >=20 > Hopefully reducing the confusion: >=20 > 1) An assumed-rank dummy argument may have the allocatable or pointer > attribute. This is based on these not being in the list of prohibited > attributes in C535a. It is also clearly the intent based on the text in > 6.3p1. >=20 > 2) The model for assumed-rank that is not allocatable or pointer is an > assumed-shape array. Both assumed-shape and assumed-rank that is > nonpointer nonallocatable come under the CFI_attribute_other category in > Table 8.1. There is not way for the C function to distinguish these case= s. >=20 > 3) If the procedure with the assumed-rank argument also has BIND(C) then > the argument passing is implemented as a pointer to a C descriptor. If > the argument is not a pointer or allocatable, then the lower bounds in > the descriptor are zero, as stated in 8.3.3. >=20 > 4) If the procedure with the assumed-rank argument does not have BIND(C) > and the argument is not a pointer or allocatable, then it should be > treated like a Fortran assumed-shape array with no lower bounds > specified and would have lower bounds of 1, I agree with this, but ... > a specified in the LBOUND > intrinsic in F2008. That text we not modified by the TS. ... not with this. The text for LBOUND refers to definitions for lower boun= ds that are provided for various cases in subsections of 5.3.8. Therefore there present= ly=20 exists no normative text that defines the agreed-upon semantics ... which i= n my=20 opinon would belong into the new "5.3.8.7 Assumed-rank entity" section that is added in TS/section 9.5. Further missing stuff would be extents for the= =20 non-pointer non-allocatable case, and size, bounds and shape otherwise (this could probably be done more economically than in the updated text bel= ow).=20 My edit was misplaced though - it should go to section 5.2 instead of 6.3, = due to the localization noted above. >=20 > 5) The proposed edit for the end of 6.3p1 is inconsistent with (3) > above. The lower bound value was intentionally omitted in 6.3p1. However, the edit is intended to refer to the Fortran side of things only.= =20 (In particular, a BIND(C) procedure may be implemented in Fortran as well, = so it is not always the case that a C descriptor is created on the call site,= but=20 this is peripheral to the argument).=20 Here a modified version of section (A): ---------------------------------------------------------------------------= --------------------------- (A) Assumed rank entities. The Fortran lower bounds of an assumed-rank dummy argument that does=20 not have the POINTER or ALLOCATABLE attribute should be one. Furthermore,=20 C532 must be loosened in order to allow assumed-rank entities to=20 have the POINTER or ALLOCATABLE attribute. EDITS:=20 In section 5.2, after C535c, insert "The lower bounds of an assumed-rank entity argument associated with a=20 non-pointer non-allocatable array are 1; its extents are those of its effective argument. The size, bounds, and shape of an unallocated allocatable or a=20 disassociated pointer assumed-rank entity are undefined; the=20 size, bounds, and shape of an allocated allocatable or an=20 associated pointer assumed-rank entity are assumed from its effective argument." The same text is added at the end of section 9.5, after C535c. Before the edits for 5.3.8.7 in section 9.5, add "{In 5.3.8.4, change C532 as follows} C532 An array with the POINTER or ALLOCATABLE attribute ~[that is not an assumed rank entity (5.3.8.7)] shall have an array-spec=20 that is a deferred-shape-spec-list." (the ~[...] text is added and hence gets underwaves). Further comment: For the C descriptor, section 8.3.3 already specifies=20 the lower bound for a non-allocatable non-pointer array as zero. ---------------------------------------------------------------------------= --------------------------- >=20 > Cheers, > Bill >=20 >=20 > On 5/28/13 11:31 AM, Daniel C Chen wrote: > > > > XL Fortran Development - IBM Toronto Software Lab > > Phone: 905-413-3056 > > Tie: 969-3056 > > Email: cdchen@ca.ibm.com > > http://www.ibm.com/software/awdtools/fortran/xlfortran > > > > Inactive hide details for "Bader, Reinhold" ---05/28/2013 > > 02:43:26---Hello Daniel, Von: j3-bounces@mailman.j3-fortran.org > > [mail"Bader, Reinhold" ---05/28/2013 02:43:26---Hello Daniel, Von: > > j3-bounces@mailman.j3-fortran.org > > [mailto:j3-bounces@mailman.j3-fortran.org] Im A > > > > From: "Bader, Reinhold" > > To: WG5 , > > Date: 05/28/2013 02:43 > > Subject: (j3.2006) (SC22WG5.5003) AW: Corrections to TS29113 > > Sent by: j3-bounces@mailman.j3-fortran.org > > > > -----------------------------------------------------------------------= - > > > > > > > > Hello Daniel, > > > > *Von:* j3-bounces@mailman.j3-fortran.org > > [mailto:j3-bounces@mailman.j3-fortran.org] *Im Auftrag von *Daniel C Ch= en* > > Gesendet:* Montag, 27. Mai 2013 23:32* > > An:* fortran standards email list for J3* > > Cc:* WG5; j3-bounces@mailman.j3-fortran.org; Bill Long* > > Betreff:* Re: (j3.2006) (SC22WG5.5001) Corrections to TS29113 > > > > "(A) Assumed rank entities. > > The Fortran lower bounds of an assumed-rank dummy argument that does no= t > > have the POINTER or ALLOCATABLE attribute should be one. > > EDIT to TS29113: > > In section 6.3, end of para 1, insert > > "If the actual argument is a non-pointer non-allocatable array, the > > lower bounds of the dummy argument have the value one." > > FIXME: corresponding edit in section 9.7 is needed." > > > > > > An assumed-rank entity is a nonallocatable and nonpointer entity. > > > > No, it is also permitted for it to have the POINTER or ALLOCATABLE > > attribute. > > > > In F2008 standard, An array with the POINTER or ALLOCATABLE attribute > > shall have deferred-shape-spec-list by > > > > C532 An array with the POINTER or ALLOCATABLE attribute shall have an > > array-spec that is a deferred-shape-spec-list. > > > > I didn't find any edit to this constraint to allow assumed-rank to be > > pointer or allocatable. Should there be an edit? Even an assumed-rank > > dummy argument can be pointer or allocatable, should the edit to 6.3 be > > read "If the dummy argument is a non-pointer non-allocatable...." > > > > As long as the corresponding actual argument is an array, the lower > > bounds of the assumed-rank dummy argument have the value one. > > I am not sure if the proposed edit to 6.3 covers this as if the dummy > > argument is not assumed-rank, for instance, it can be explicit shape > > with low bounds declared other than one. > > > > To my understanding, all restrictions in paragraph 1 of 6.3 presuppose > > assumed-rank dummy entities. > > > > > > > > Daniel > > > > > > XL Fortran Development - IBM Toronto Software Lab > > Phone: 905-413-3056 > > Tie: 969-3056 > > Email: _cdchen@ca.ibm.com_ _ > > __http://www.ibm.com/software/awdtools/fortran/xlfortran_ > > > > Inactive hide details for "Bader, Reinhold" ---05/27/2013 > > 15:50:16---Hello Bill, based on Tobias' implementation experience > > as"Bader, Reinhold" ---05/27/2013 15:50:16---Hello Bill, based on > > Tobias' implementation experience as well as observations by others, I > > have as > > > > From: "Bader, Reinhold" <_Reinhold.Bader@lrz.de_ > > > > > To: Bill Long <_longb@cray.com_ >, > > Cc: WG5 <_sc22wg5@open-std.org_ > > > Date: 05/27/2013 15:50 > > Subject: (j3.2006) (SC22WG5.5001) Corrections to TS29113 > > Sent by: _j3-bounces@mailman.j3-fortran.org_ > > > > > > -----------------------------------------------------------------------= - > > > > > > > > > > Hello Bill, > > > > based on Tobias' implementation experience as well as observations by > > others, I have assembled > > a "fix paper draft" for a number of glitches and omissions to the > > interop TS. Since you were going to write a > > paper on a minor extension anyway (cf. item "D" in the attached draft), > > the question is whether to > > put all this into one paper, or to write a number of separate ones. > > Furthermore, feedback on the > > suggestions in the draft is welcome. > > > > Best wishes > > Reinhold > > > > > > [attachment "ts29113_corrections.txt" deleted by Daniel C > > Chen/Toronto/IBM] _______________________________________________ > > J3 mailing list_ > > __J3@mailman.j3-fortran.org_ _ > > __http://mailman.j3- > fortran.org/mailman/listinfo/j3_______________________________________ > _________ > > J3 mailing list > > J3@mailman.j3-fortran.org > > http://mailman.j3-fortran.org/mailman/listinfo/j3 > > > > > > > > _______________________________________________ > > J3 mailing list > > J3@mailman.j3-fortran.org > > http://mailman.j3-fortran.org/mailman/listinfo/j3 > > >=20 > -- > Bill Long longb@cray.com > Fortran Technical Support & voice: 651-605-9024 > Bioinformatics Software Development fax: 651-605-9142 > Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101 >=20