(j3.2006) Nothing at all to do with locality
Malcolm Cohen
malcolm
Tue Jul 18 01:24:49 EDT 2017
I do prefer the subject of an email to have something to do with the contents!
Anyway, I take Daniel?s point that the description of where an entity is declared when it is implicit typed does not work for construct entities of BLOCK constructs. Obviously these should be treated as declared in the BLOCK scope, but the wording does not achieve that (in fact the wording achieves nothing useful at all, since any declaration in the host scope would be of an inaccessible host entity!).
I don?t agree that the example is not conforming just because one sentence in the standard is useless though. It?s only the ?The data entity is treated as if? sentence which is wrong, and that sentence is unnecessary seeing as how the semantics are actually fully described by the rest of the paragraph.
Actually I think the sentence also does not work for array-constructor implied-do variables either; these are statement entities! That sentence would imply that the ac-ido index variable ?leaks out of? the array constructor, e.g. into a module scope, and we know that they don?t do that.
Given there seems to be multiple problems with the sentence we should probably delete it. If it is thought useful, it will probably need to be a new paragraph by itself, as describing all the various exceptions to the simple ?inclusive scope? rule (which only applies to local entities, not to statement or construct entities) is almost certainly going to be complicated. Alternatively we could just change ?The data entity is treated as if? to ?If the data entity is a local entity, it is treated as if?, and leave the statement and construct entities to be handled by the semantics without saying they are like anything else.
Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.
From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Daniel C Chen
Sent: Tuesday, July 18, 2017 3:47 AM
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Subject: Re: (j3.2006) Locality problems not repaired at Garching
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 <mailto:cdchen at ca.ibm.com>
http://www.ibm.com/software/awdtools/fortran/xlfortran
Bill Long ---07/17/2017 01:41:54 PM---> On Jul 17, 2017, at 12:12 PM, Daniel C Chen <cdchen at ca.ibm.com <mailto:cdchen at ca.ibm.com> > wrote: >
From: Bill Long <longb at cray.com <mailto:longb at cray.com> >
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org <mailto: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 <mailto:j3-bounces at mailman.j3-fortran.org>
_____
> On Jul 17, 2017, at 12: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?
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 <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
Bill Long longb at cray.com <mailto: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 <mailto:J3 at mailman.j3-fortran.org>
http://mailman.j3-fortran.org/mailman/listinfo/j3
Disclaimer
The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170718/9dd47715/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mailman.j3-fortran.org/pipermail/j3/attachments/20170718/9dd47715/attachment-0001.gif
More information about the J3
mailing list