(j3.2006) Locality problems not repaired at Garching
Daniel C Chen
cdchen
Mon Jul 17 14:46:49 EDT 2017
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
http://www.ibm.com/software/awdtools/fortran/xlfortran
From: Bill Long <longb at cray.com>
To: fortran standards email list for J3 <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
> 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
_______________________________________________
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/80f3e0e5/attachment.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/80f3e0e5/attachment.gif
More information about the J3
mailing list