(j3.2006) Locality problems not repaired at Garching

[Bill Long]

> On Jul 17, 2017, at 12:12 PM, Daniel C Chen <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
> 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>
> To: 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
> 
> 
> 
> 
> 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
> http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       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