(j3.2006) Locality problems not repaired at Garching

[Daniel C Chen]

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



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.

--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."

--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.

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..?

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.

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.

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.)


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.

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.


_______________________________________________
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/156362ea/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/20170714/156362ea/attachment.gif