(j3.2006) Locality problems not repaired at Garching
Daniel C Chen
cdchen
Mon Jul 17 14:39:49 EDT 2017
Hi Tom,
It was my understanding too, but after reading 8.7p4 (it describes the
implicit-typing rule regardless if a IMPLICIT statement appears or not)
"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."
And the definition of inclusive scope is
"inclusive scope
nonblock scoping unit plus every block scoping unit whose host is that
scoping unit or that is nested within such a block scoping unit
NOTE 3.5
That is, inclusive scope is the scope as if BLOCK constructs were not
scoping units."
Does it mean R in the following code should be implicit-declared in the
host scope of the BLOCK construct? Since both BLOCK construct has a common
host scope, R in the 2nd BLOCK construct is invalid?
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
From: "Clune, Thomas L. (GSFC-6101)" <thomas.l.clune at nasa.gov>
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Cc: "Van.Snyder at jpl.nasa.gov" <Van.Snyder at jpl.nasa.gov>
Date: 07/17/2017 01:23 PM
Subject: Re: (j3.2006) Locality problems not repaired at Garching
Sent by: j3-bounces at mailman.j3-fortran.org
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> 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
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
_______________________________________________
J3 mailing list
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/b38825c2/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20170717/b38825c2/attachment-0001.gif
More information about the J3
mailing list