From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Dec 5 00:44:03 2014 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 B0B5035852E; Fri, 5 Dec 2014 00:44:03 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from postout1.mail.lrz.de (postout1.mail.lrz.de [129.187.255.137]) by www.open-std.org (Postfix) with ESMTP id 3D92D35672C for ; Fri, 5 Dec 2014 00:43:59 +0100 (CET) Received: from lxmhs51.srv.lrz.de (localhost [127.0.0.1]) by postout1.mail.lrz.de (Postfix) with ESMTP id 3jttt66v7mzyRw for ; Fri, 5 Dec 2014 00:43:58 +0100 (CET) Authentication-Results: postout.lrz.de (amavisd-new); dkim=pass (2048-bit key) reason="pass (just generated, assumed good)" header.d=lrz.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=lrz.de; h= mime-version:content-transfer-encoding:content-type:content-type :content-language:accept-language:in-reply-to:references :message-id:date:date:subject:subject:from:from:received :received:received:received; s=postout; t=1417736638; bh=bwL8pdG I/H03H4Et7/vWNdrUXeo6ANXy0rEfDqMUMvg=; b=nHUyz2GNKF83iR0f5bALT4i YdP1+HWsKWinQ1fa4iR4ncWtNWRZCl1ATXY4kjg/+hZd5ND0qIhbdaEWtJFq7RBG 9S0hnMaFbYXTnV7JC1Cdq+ADQME7GsY8FhryVAQhtZ45y6gKHOH0sGlv9nWHA8VU GA5Wpfx8SGuKFQzBJWOmb5bCdgNbzdxXGRvdhsTYWbo0A7sfc/3ZwKlvIKnVpY2R cdpmOG9jKrUqrSQ+yGEo2sK4elGjzA7HovSlu6/Z3J6b6KYFgoyA0RMnremPp087 ctUz8oqmnF4UNazAy2nyDhe+QiLGBxuAGbGD0owgR2J04SUVC2aDy2811bGpmLQ= = X-Virus-Scanned: by amavisd-new at lrz.de in lxmhs51.srv.lrz.de X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LRZ_DATE_TZ_0000=0.001, LRZ_DKIM_DESTROY_MTA=0.001, LRZ_DMARC_OVERWRITE=0.001, LRZ_FROM_AP_PHRASE=0.001, LRZ_FROM_PHRASE=0.001, LRZ_FROM_PRE_SUR_ADDR=0.001, LRZ_FWD_MS_EX=0.001, LRZ_HAS_X_ORIG_IP=0.001, LRZ_MSGID_HL32=0.001, LRZ_MSGID_SPAM_68=0.001, LRZ_RCVD_MS_EX=0.001, SPF_HELO_NONE=0.001] autolearn=no Received: from postout1.mail.lrz.de ([127.0.0.1]) by lxmhs51.srv.lrz.de (lxmhs51.srv.lrz.de [127.0.0.1]) (amavisd-new, port 20024) with LMTP id sjR-MsFaGfGK for ; Fri, 5 Dec 2014 00:43:58 +0100 (CET) Received: from BADWLRZ-SW13MB3.ads.mwn.de (BADWLRZ-SW13MB3.ads.mwn.de [IPv6:2001:4ca0:0:108::151]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "BADWLRZ-SW13MB3", Issuer "BADWLRZ-SW13MB3" (not verified)) by postout1.mail.lrz.de (Postfix) with ESMTPS id 3jttt62X0dzyRW for ; Fri, 5 Dec 2014 00:43:58 +0100 (CET) Received: from BADWLRZ-SW13MB1.ads.mwn.de (2001:4ca0:0:108::155) by BADWLRZ-SW13MB3.ads.mwn.de (2001:4ca0:0:108::151) with Microsoft SMTP Server (TLS) id 15.0.995.29; Fri, 5 Dec 2014 00:43:57 +0100 Received: from BADWLRZ-SW13MB1.ads.mwn.de ([fe80::89:5514:4b27:d8be]) by BADWLRZ-SW13MB1.ads.mwn.de ([fe80::89:5514:4b27:d8be%12]) with mapi id 15.00.0995.028; Fri, 5 Dec 2014 00:43:57 +0100 From: "Bader, Reinhold" To: WG5 Subject: AW: (j3.2006) (SC22WG5.5369) Question on PURE subroutines Thread-Topic: (j3.2006) (SC22WG5.5369) Question on PURE subroutines Thread-Index: AdAP4M/rJll26hGBT5a6eQ7bW9hqCAAFB58AAAOVnQAAAGdqAAAFcqTQ Date: Thu, 4 Dec 2014 23:43:56 +0000 Message-ID: <2f9ca0733ef04385b1a2c813d14e5843@BADWLRZ-SW13MB1.ads.mwn.de> References: <20141204170247.9A28E35837D@www.open-std.org> <1417723384.30072.318.camel@math.jpl.nasa.gov> <8790C6A6-7186-4DD4-9B1E-A38DDC3CA0A8@cray.com> <1417730236.30072.347.camel@math.jpl.nasa.gov> In-Reply-To: <1417730236.30072.347.camel@math.jpl.nasa.gov> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [79.192.251.190] 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 > -----Urspr=FCngliche Nachricht----- > Von: j3-bounces@mailman.j3-fortran.org [mailto:j3-bounces@mailman.j3- > fortran.org] Im Auftrag von Van Snyder > Gesendet: Donnerstag, 4. Dezember 2014 22:57 > An: j3 > Betreff: Re: (j3.2006) (SC22WG5.5369) Question on PURE subroutines >=20 > On Thu, 2014-12-04 at 21:45 +0000, Bill Long wrote: > > On Dec 4, 2014, at 2:03 PM, Van Snyder wrote: > > > > > On Thu, 2014-12-04 at 16:55 +0000, Bader, Reinhold wrote: > > >> Hello all, > > >> > > >> > > >> > > >> consider the program > > >> > > >> > > >> > > >> module mod_proc_cont_01 > > >> > > >> implicit none > > >> > > >> type :: cont > > >> > > >> real, pointer :: p(:) =3D> null() > > >> > > >> end type cont > > >> > > >> real, target :: p(2) > > >> > > >> contains > > >> > > >> pure subroutine pf(x) > > >> > > >> type(cont), intent(inout) :: x > > >> > > >> integer :: i > > >> > > >> > > >> > > >> if (associated(x%p)) then > > >> > > >> x%p =3D [ (real(2*i), i=3D1, size(x%p)) ] > > >> > > >> end if > > >> > > >> end subroutine pf > > >> > > >> end module mod_proc_cont_01 > > >> > > >> program proc_cont_01 > > >> > > >> use mod_proc_cont_01 > > >> > > >> implicit none > > >> > > >> type(cont) :: xx > > >> > > >> > > >> > > >> p =3D [ 1.0, 2.0 ] > > >> > > >> xx%p =3D> p > > >> > > >> call pf(xx) > > >> > > >> write(*,*) p > > >> > > >> end program proc_cont_01 > > >> > > >> > > >> > > >> > > >> > > >> It appears to conform to the Fortran 2008 standard; it is accepted b= y > > >> the compilers available to me. Yet it > > >> > > >> appears to implement a side effect in a PURE procedure. Was this > > >> intended? If not, would adding the following > > >> > > >> text in 007 fix the problem? > > >> > > >> > > >> > > >> [312:30] After "any designator", add " with the POINTER attribute or= " > > > > > > Assuming this is in the first line of C1283 in F08, it goes a bit too > > > far. It effectively prevents meaningful use of pointers within pure > > > procedures. Agreed. Locally declared objects should still work.=20 > > > > > > For example, if you have several local variables upon which the code > > > needs to act in several places, instead of repeating the test through= out > > > the code, do the test once and associate a pointer with the necessary > > > variable. The proposed change to C1283 would make it impossible to > > > assign a value using that pointer. > > > > > > The issue that Reinhold points out is the case of a pointer appearing > > in a variable definition context when its target is not a local > > variable, but one that is declared in the specification part of a > > module. We prohibit direct definition of such a variable in a pure > > procedure, so to seems reasonable to also prohibit definition of a > > pointer associated with such a variable. NOTE 12.49 ("pure procedures for morons") seems to think along the same lin= es ...=20 so if the program is determined to stay conforming, perhaps some rewording = of=20 that NOTE is needed? >=20 > We constrain against direct assignment to such a variable in a pure > procedure, but not against indirect assignment, for example, if a dummy > argument is a pointer. Reinhold's example is no different from one > where the pointer is the dummy argument, not a component of the dummy > argument. The case of a pointer dummy argument would also be covered by the augmented= restriction (see below for an improved version). >=20 > There are in fact no nonconstraint prohibitions involving what can be > done within pure procedures. We cannot constrain against what Reinhold > wants to prohibit without crippling the use of pointers within pure > procedures. How about following improved edit:=20 [312:30] After "any designator", add " with the POINTER attribute and a bas= e object that is a dummy argument, as well as any designator " Cheers Reinhold >=20 > Prohibiting this behavior other than by constraint would be a new thing. >=20 > > > > Cheers, > > Bill > > > > > > > > > > > > I'm not convinced this is an undesirable side effect, but if it is, a > > > much more elaborate prohibition would be needed, to prevent a pointer > > > component of a dummy argument from appearing in a variable definition > > > context or as the data target in a pointer assignment statement. > > > > > >> Cheers > > >> > > >> Reinhold > > >> > > >> > > >> > > >> > > >> _______________________________________________ > > >> 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 > > > > Bill Long = longb@cray.com > > Fortran Technical Suport & voice: 65= 1-605-9024 > > Bioinformatics Software Development fax: 651-605-9= 142 > > Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101 > > > > >=20 >=20 > _______________________________________________ > J3 mailing list > J3@mailman.j3-fortran.org > http://mailman.j3-fortran.org/mailman/listinfo/j3