(j3.2006) Locality problems not repaired at Garching

Clune, Thomas L. GSFC-6101 thomas.l.clune
Mon Jul 17 13:22:58 EDT 2017


Danial,

I disagree.  The example code is just fine.   R in each scope is a _different_ entity.   They just happened to both get their type by implicit typing rules.

As an applications person (as opposed to a vendor), I?m quite tempted to simply ignore all examples that don?t include IMPLICIT NONE.  :-)


- Tom


On Jul 17, 2017, at 1: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?
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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170717/2ae4323e/attachment-0001.html 



More information about the J3 mailing list