(j3.2006) Locality problems not repaired at Garching
Van Snyder
Van.Snyder
Fri Jul 14 21:23:22 EDT 2017
On Fri, 2017-07-14 at 14:51 -0400, Daniel C Chen wrote:
> My attempt to answer some of the questions....
>
> 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
>
> Inactive hide details for Van Snyder ---07/13/2017 06:45:50 PM---These
> might be nothingburgers, but they weren't discussed at GVan Snyder
> ---07/13/2017 06:45:50 PM---These might be nothingburgers, but they
> weren't discussed at Garching, and I can't find convincing a
>
> From: Van Snyder <Van.Snyder at jpl.nasa.gov>
> To: j3 <j3 at j3-fortran.org>
> Date: 07/13/2017 06:45 PM
> Subject: (j3.2006) Locality problems not repaired at Garching
> Sent by: j3-bounces at mailman.j3-fortran.org
>
>
>
> ______________________________________________________________________
>
>
>
> These might be nothingburgers, but they weren't discussed at Garching,
> and I can't find convincing answers.
>
> C1129 says that if DEFAULT(NONE) appears in a DO CONCURRENT statement,
> a
> variable that appears in the block of the construct and is not an
> index
> name shall have its locality explicitly specified.
>
> Does a variable declared in a BLOCK construct within a DO CONCURRENT
> construct, or the associate name in an ASSOCIATE construct, or a
> statement entity such as an <ac-do-variable>, appear in the block of
> the
> DO CONCURRENT construct? That seems to be the case.
The above paragraph was a prelude to the next three, which need to be
taken together. Three paragraphs below I offered a proposed repair.
> --Daniel: I believe C1129 is aiming variables that are accessible in
> the
> enclosing scope of the DO CONCURRENT construct, so these cases should
> be
> excluded.
> It seems absurd to require such a variable to be declared in the
> enclosing scope, and then declared to have some specific locality, and
> then declared in the BLOCK construct, wherein it behaves as though it
> had local locality, but with possibly different characteristics,
> notwithstanding the locality spec.
>
> In C1129 do we need to insert ", is not a statement or construct
> entity
> of a statement or construct within that construct," after <block> of
> the
> construct" giving:
>
> "C1129 If the <locality-spec> DEFAULT ( NONE ) appears in a DO
> CONCURRENT
> statement, a variable that appears in the <block> of that
> construct,
> is not a statement or construct entity of a statement or
> construct
> within that construct, and is not an <index-name> of that
> construct
> shall have its locality explicitly specified."
We can't simply use
"C1129 If the <locality-spec> DEFAULT ( NONE ) appears in a DO CONCURRENT
statement, a variable that is a construct entity of that construct
and is not an <index-name> of that construct shall have its locality
explicitly specified."
because variables with shared or unspecified locality are not construct entities of the DO CONCURRENT construct.
> --Daniel: Even though C1129 doesnt' explicitly exclude the cases listed at
>
> the above, C1124 actually requires variables-name in a
> locality-spec must be the name of a variable in the innermost
> executable
> construct or scoping unit that includes the DO CONCURRENT statement.
> Therefore, I think C1129 is fine as is as in conjunction with C1124,
> those
> cases are excluded.
It is absurd to require that an explicitly-declared variable in a BLOCK
construct be explicitly declared in the surrounding scope, and then be
declared to have local locality, when an explicit declaration in a BLOCK
construct ought to be enough to make it behave as a variable with local
locality.
do concurrent ( integer :: i = 1:10 ) default ( none )
block
real :: R ! Why is this prohibited by C1129?
end block
end do
C1129 requires this to be
real :: R
do concurrent ( integer :: i = 1:10 ) local ( r ), default ( none )
block
real :: R
end block
end do
The R declared in the outer scope allows us to specify that a construct
entity of the DO CONCURRENT construct of the same same name has
locality, but that construct entity is never used in the DO CONCURRENT
construct. The only purpose of the outer declaration and the locality
spec are to allow the entirely unrelated declaration of R, which is not
a construct entity of the DO CONCURRENT construct, within the BLOCK
construct. Did we intentionally shoot ourselves in this foot?
It is absurd that an associate name has to be the name of a declared
variable in the enclosing scope:
do concurrent ( integer :: i = 1:10 ) default ( none )
associate ( r => a(i) ) ! Why is this prohibited by C1129?
end associate
end do
C1129 requires this to be
real :: R
do concurrent ( integer :: i = 1:10 ) local ( r ), default ( none )
associate ( r => a(i) )
end associate
end do
Again, the R declared in the outer scope allows us to specify that a
construct entity of the DO CONCURRENT construct of the same same name
has locality, but that construct entity is never used in the DO
CONCURRENT construct. The only purpose of the outer declaration and the
locality spec are to allow the entirely unrelated associate name R,
which is not a construct entity of the DO CONCURRENT construct, to
appear. Did we intentionally shoot ourselves in this foot?
It is absurd that an ac-do-variable has to be the name of a declared
variable in the enclosing scope:
do concurrent ( integer :: i = 1:10 ) default ( none )
a(i,1:3) = [ (j, integer :: j = 1:5:2) ] ! Why is this
prohibited by C1129?
end do
C1129 requires this to be
integer :: J
do concurrent ( integer :: i = 1:10 ) local ( j ), default ( none )
a(i,1:3) = [ (j, integer :: j = 1:5:2) ]
end do
Again, the R declared in the outer scope allows us to specify that a
construct entity of the DO CONCURRENT construct of the same same name
has locality, but that construct entity is never used in the DO
CONCURRENT construct. The only purpose of the outer declaration and the
locality spec are to allow the entirely unrelated ac-do-variable I,
which is not a construct entity of the DO CONCURRENT construct, to
appear. Did we intentionally shoot ourselves in this foot?
> Is a variable permitted to appear only within a BLOCK construct within
> a
> DO CONCURRENT construct that has DEFAULT ( NONE ) if IMPLICIT NONE is
> in
> effect?
>
> --Daniel: I didn't get the issue..?
Sorry, it's not IMPLICIT NONE, it's implicit typing
do concurrent ( integer :: i = 1:10 ) default none
block
r = cos(a ( i )) ! Why is this prohibited by C1129? R is not a
construct entity of the DO CONCURRENT construct.
end block
end do
>
> This rests upon a deeper question that might be addressed
> somewhere, but I couldn't find an answer: If an implicitly-declared
> variable appears only within a BLOCK construct (or several disjoint
> ones), is it a construct entity of that (those) BLOCK construct(s)?
> In
> particular, if it appears in several disjoint BLOCK constructs, is it
> the same variable in all of them, or a different variable in each one?
> Does 3.39 make it a different variable in each construct?
>
> --Daniel: I think each disjoint BLOCK construct should have a
> different
> variable as the implicit typing applies to a particular scoping unit.
I think that's what 8.7p4 says.
> If a variable specified to have local locality is the name of a common
> variable, is it still a common variable? The word "common" does not
> appear in subclause 11.1.7.
>
> --Daniel: I don't think the corresponding construct entity is a
> common
> variable.
11.1.7.5p2 doesn't say it is or it isn't.
> What is the relationship between locality specs and
> implicitly-declared
> variables? C1124 doesn't illuminate this question. If a variable is
> mentioned in a locality spec but does not appear in the scoping unit
> containing the DO CONCURRENT statement, is it implicitly declared? If
> it has local locality, it is a construct entity, and has a scope of
> the
> construct, so it can't be implicitly declared in the enclosing scope.
>
> --Daniel: A variable in the locality spec should have been either
> explicitly or implicitly declared prior to the DO CONCURRENT
> statement.
> Otherwise, it should be an error. (I.E. the corresponding construct
> entity
> should not be implicitly declared.)
C1124 doesn't say that. Does the appearance of a variable in a
locality-spec implicitly declare it, or not?
> If a variable has specified locality, does it have the same locality
> in
> a DO CONCURRENT construct within the one where it is declared to have
> that locality if the inner one doesn't have a locality spec? How
> about
> if it has a conflicting locality spec?
>
> --Daniel: NO. The locality-spec is per DO CONCURRENT construct. A
> variable
> that has LOCAL locality in the outer DO CONCURRENT can definitely
> have
> SHARED locality in an nested inner DO CONCURRENT construct.
If a variable has local locality in an outer DO CONCURRENT construct,
and an inner one has no locality spec, what is its locality in the inner
construct? 11.1.7.5p1 says "appears in a DO CONCURRENT construct," not
"appears in a DO CONCURRENT construct and not in a contained DO
CONCURRENT construct" Without a locality spec on the inner construct,
it appears that the locality spec for the outer one applies. It ought
to be unspecified. But that's not what 11.1.7.5 says. Indeed, 11.1.7.5
doesn't say anything about contained constructs. From 11.1.7.5p1, one
could conclude that such a variable in an inner construct has both local
and unspecified locality. We can't just use "construct entity" instead
of "appears" in 11.1.7.5p1 because variables with shared or unspecified
locality are not construct entities. This wasn't carefully enough
crafted. I warned about this four times.
> One might argue that some of these problems don't arise because
> variables with local locality are construct entities, but C1127
> clearly
> contemplates some relationship between variables with local locality
> and
> the ones from which they get their characteristics, in that it
> prohibits
> ones that are prohibited from appearing in a variable definition
> context
> (e.g., a variable with INTENT(IN), or one with the PROTECTED attribute
> and accessed by use association) from having LOCAL locality. This
> suggests they're not construct entities, notwithstanding that
> 11.1.7.5p2
> says they are. Oddly, after C1127, 11.1.7.5p2 says a variable with
> local locality does not have the PROTECTED or INTENT attribute.
>
> These problems were pointed out in 17-144r1, which apparently nobody
> read beyond the subject line.
Can these problems be repaired now, or should we plan on processing
interps and publishing a corrigendum before the standard is actually
published?
_______________________________________________
> 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/20170714/18370d18/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/20170714/18370d18/attachment-0001.gif
More information about the J3
mailing list