(j3.2006) Locality problems not repaired at Garching

[Van Snyder]

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.