(j3.2006) Locality problems not repaired at Garching
Clune, Thomas L. GSFC-6101
thomas.l.clune
Mon Jul 17 14:52:40 EDT 2017
I can?t comment on what the current wording _requires_. But I would regard anything other than those entities being only in the scope of the BLOCK to be a defect in the standard.
On Jul 17, 2017, at 2:46 PM, Daniel C Chen <cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>> wrote:
Sure. I see 8.7p4 describes implicit-typing rule regardless if an IMPLICIT statement is specified or not even though it is under the IMPLICIT statement section.
I guess what I am not clear is if an identifier that only appears in a BLOCK construct should be implicit-declared in the host scope of the BLOCK construct or in the BLOCK construct scoping unit.
It seems 8.7p4 plus the definition of "inclusive scope" suggests the host scope is where it belongs, which I think makes the code not conforming.
Thanks,
Daniel
XL Fortran Development, Fortran Standard Representative
IBM Toronto Software Lab
Phone: 905-413-3056
Tie: 969-3056
Email: cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>
http://www.ibm.com/software/awdtools/fortran/xlfortran
<graycol.gif>Bill Long ---07/17/2017 01:41:54 PM---> On Jul 17, 2017, at 12:12 PM, Daniel C Chen <cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>> wrote: >
From: Bill Long <longb at cray.com<mailto:longb at cray.com>>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: 07/17/2017 01:41 PM
Subject: Re: (j3.2006) Locality problems not repaired at Garching
Sent by: j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>
________________________________
> On Jul 17, 2017, at 12:12 PM, Daniel C Chen <cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>> wrote:
>
> If the IMPLICIT statement is not allowed in a BLOCK construct as Malcolm indicated, should 8.7p4 become moot as it only applies to IMPLICIT statement?
8.7p4 does not appear limited to BLOCK considerations. It seems much more general than that.
> Then the following quoted code becomes not conforming because R is implicitly-declared to have rank 1 in the enclosing scope of the first BLOCK construct (as per 19.4), and should not be implicit-declared with a different rank is the same scoping unit. Although XLF 15.1.5 prints the same as ifort and nagfor.
I?d say that the rank of R is *explicitly* declared in both cases.
Cheers,
Bill
>
> block
> dimension R(3)
> print '(a,i0)', 'Shape(R) = ', shape(r)
> end block
>
> block
> dimension R(2,2)
> print '(a,2(1x,i0))', 'Shape(R) =', shape(r)
> end block
>
> end
>
> prints
>
> Shape(R) = 3
> Shape(R) = 2 2
>
> Thanks,
>
> Daniel
>
> XL Fortran Development, Fortran Standard Representative
> IBM Toronto Software Lab
> Phone: 905-413-3056
> Tie: 969-3056
> Email: cdchen at ca.ibm.com<mailto:cdchen at ca.ibm.com>
> http://www.ibm.com/software/awdtools/fortran/xlfortran
>
> <graycol.gif>Van Snyder ---07/14/2017 09:01:33 PM---On Sat, 2017-07-15 at 09:20 +0900, Malcolm Cohen wrote: > I note that if BLOCK affected implicitly d
>
> From: Van Snyder <Van.Snyder at jpl.nasa.gov<mailto:Van.Snyder at jpl.nasa.gov>>
> To: j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>
> Date: 07/14/2017 09:01 PM
> Subject: Re: (j3.2006) Locality problems not repaired at Garching
> Sent by: j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>
>
>
>
>
> On Sat, 2017-07-15 at 09:20 +0900, Malcolm Cohen wrote:
> > I note that if BLOCK affected implicitly declared entities, it would be
> > extremely error-prone to add to existing code, and indeed if that were the
> > case BLOCK would have been an extremely bad construct. Fortunately, that is
> > not the case, BLOCK has no effect on implicitly declared entities.
>
> It has no effect on implicitly-declared entities in the enclosing scope,
> which is a good thing.
>
> But concerning implicit declaration, 8.7p4 says "The data entity is
> treated as if it were declared in an explicit type declaration; if the
> outermost inclusive scope in which it appears is not a type definition,
> it is declared in that scope, otherwise it is declared in the host of
> that scope."
>
> A BLOCK construct isn't a type definition, so read this as "The data
> entity is treated as if it were declared in an explicit type
> declaration; it is declared in the outermmost inclusive scope in which
> it appears." If it only appears in a BLOCK construct, that is the
> outermost inclusive scopes in which it appears.
>
> So, although IMPLICIT NONE is not allowed in BLOCK constructs,
> implicitly typed variables in them do exist and are construct entities
> of those BLOCK constructs because the effect is as they were declared by
> explicit type declarations in those constructs (according to 8.7p4).
> Although they have the same type and kind in each BLOCK construct, they
> are different in each pair of disjoint BLOCK constructs in which they
> appear. They could have different ranks and shapes (DIMENSION statement
> is allowed) or they might be variables in some and named constants in
> others (PARAMETER statement is allowed).
>
> This program
>
> block
> dimension R(3)
> print '(a,i0)', 'Shape(R) = ', shape(r)
> end block
>
> block
> dimension R(2,2)
> print '(a,2(1x,i0))', 'Shape(R) =', shape(r)
> end block
>
> end
>
> prints
>
> Shape(R) = 3
> Shape(R) = 2 2
>
> with ifort 16.0.2.181 and nagfor Build 6117.
>
> Since IMPLICIT NONE is not allowed in BLOCK constructs, Erik's question
> is moot, but since implicitly declared variables in BLOCK constructs
> exist, one might still wonder whether we intended to prohibit
>
> do concurrent ( integer :: i = 1:10 ) default ( none )
> block
> r = cos(a(i))
> end block
> end do
>
> with implicit typing in effect, in which R is an implicitly-declared
> construct entity of the BLOCK construct, but "appears" in the <block> of
> the DO CONCURRENT construct.
>
> Similarly, we appear to have prohibited
>
> do concurrent ( integer :: i = 1:10 ) default ( none )
> block
> real :: R
> end block
> end do
>
> in which R is an explicitly-declared construct entity of the BLOCK
> construct, but "appears" in the <block> of the DO CONCURRENT construct,
> and
>
> do concurrent ( integer :: i = 1:10 ) default ( none )
> associate ( r => a(i) )
> end associate
> end do
>
> in which R is a construct entity of the ASSOCIATE construct, but
> "appears" in the <block> of the DO CONCURRENT construct, and
>
> do concurrent ( integer :: i = 1:10 ) default ( none )
> a(i,1:3) = [ ( j, integer :: j = 1,5,2) ]
> end do
>
> in which J is a statement entity of the array constructor, but "appears"
> in the <block> of the DO CONCURRENT construct.
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
>
>
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
> http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long longb at cray.com<mailto:longb at cray.com>
Principal Engineer, Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org<mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170717/158b9427/attachment-0001.html
More information about the J3
mailing list