[J3] [SC22WG5.6486] Subobject of a variable

[Jeff Hammond]

If a variable has unspecified locality,

- if it is referenced in an iteration it shall either be previously defined during that iteration, or shall not be defined or become undefined during any other iteration; if it is defined or becomes undefined by more than one iteration it becomes undefined when the loop terminates;

real, dimension(10) :: A

do concurrent (integer :: k=1:size(A))
  A(k) = k
  if (k.eq.1) A(10) = 0
end do

As best I can tell, A(1:9) are defined after the loop terminates, while A(10) and A are not.  Does the fact that A is undefined before and becomes undefined during this loop imply anything about the undefined-ness of its elements during the loop or must one reason about them strictly independently, based on the element-wise defined/undefined-ness?

Now suppose I make A shared.  Malcolm said all the elements of A are shared as well "It’s not written there now, because, like, how could it possibly be anything else?”

real, dimension(10) :: A

do concurrent (integer :: k=1:size(A)) shared(A)
  A(k) = k
  if (k.eq.1) A(10) = 0
end do

It is odd to me that the shared-ness of A propagates to its elements but the undefined-ness does not.  Why must I reason about the element-wise behavior of an array independent of the array itself when worrying about whether a variable becomes undefined or defined during a loop, but in the same context, they are obviously not independent regarding locality?

Jeff


On 19. Sep 2023, at 10.49, Malcolm Cohen via J3 <j3 at mailman.j3-fortran.org> wrote:

External email: Use caution opening links or attachments

Hi Brad,

There is no doubt that subobject includes array elements.

The point is that a subobject of a variable is itself a variable. So nothing more needs to be said on that front.

But in the case of a subobject of a constant, that is often not constant. E.g.
   INTEGER,PARAMETER :: x(10) = [ 1,2,3,4,5,6,7,8,9,10 ]
   READ *,I
   PRINT *,x(I)

Here, X(I) is not a variable, and is also not a constant. It is a non-constant subobject of a constant!

That is what those words are there for. They are not intended to imply that subobjects of a variable are not data objects. They are simply because they are also variables, indeed, portions that can be defined and redefined separately, and being capable of being defined and redefined makes them variables.

We could add a NOTE to say that “A subobject of a variable is a variable, but a subobject of a constant is not necessarily itself constant, e.g. if it has a non-constant subscript.” Not sure it is really worth it though, at least, not until we decide what to do with our overly-large set of terms.

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.

From: Brad Richardson <everythingfunctional at protonmail.com<mailto:everythingfunctional at protonmail.com>>
Sent: Thursday, September 14, 2023 10:25 PM
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>; 'WG5' <sc22wg5 at open-std.org<mailto:sc22wg5 at open-std.org>>
Subject: [ukfortran] [SC22WG5.6484] [J3] RE: [EXTERNAL] [BULK] are race conditions allowed in do concurrent?

Hi Malcolm,

> >variable/data entity/data object
> >[are] circular, and doesn't seem to include individual array elements

> Yes it does, see 3.138 subobject.

While I see that it probably intends to include it, what it actually says is

subobject of a constant

so the edit would be to change it to

subobject of a variable or constant

I don't think the circularity is causing too much confusion, so I don't see much urgency in trying to fix it, and don't quite see an easy way to do so. I think we can leave it for now.

Regards,
Brad

On Thu, 2023-09-14 at 14:04 +0900, Malcolm Cohen via J3 wrote:
Hi Brad,

There is no contradiction, subtle or otherwise, here.

Locality-specs are only for named variables. However, as noted, subobjects of variables are also variables.

> The way I've heard "definition" applied to arrays is that definition of an element of an array does not constitute definition of the variable,

Correct (except in the trivial case of an array with a single element). This is all spelled out explicitly: defining every “part” of a multi-part variable defines the variable.

I can see some potential wording improvements for the next revision, but nothing that rises to the level of a defect.

E.g. it may be better to mention that “if a variable has SHARED locality, all of its subobjects have SHARED locality”. It’s not written there now, because, like, how could it possibly be anything else? There is nothing else it could be.  But making it explicit would lead naturally into writing “If a variable with SHARED locality is defined…” instead of the current “If it is defined…”.

>variable/data entity/data object
>[are] circular, and doesn't seem to include individual array elements

Yes it does, see 3.138 subobject.

The circularity is unfortunate, but they are all reasonably worded for comprehensibility (not for trail-following). So it’s either deleting one of them (ugh) or rewording one to break the circle without making it hard to understand (it’s not obvious exactly what to do here, which is why it is still like this).

If it were a glossary of terms, instead of a list of definitions, there would be no problem with circularity, right?

Anyway, I agree it would be good to fix it as long as it doesn’t make any individual term hard to understand.

Given our experience this time around, I would be in favour of pruning our terms and definitions, down to a more minimal set. If there are “useful” terms that do not lend themselves to trivial drop-in replacement, and I think there are, we could consider adding a “Glossary” (of “useful terms”, but probably better not to call them “terms”!).

Cheers,
--
..............Malcolm Cohen, NAG Oxford/Tokyo.

From: Brad Richardson <everythingfunctional at protonmail.com<mailto:everythingfunctional at protonmail.com>>
Sent: Wednesday, September 13, 2023 3:49 AM
To: General J3 interest list <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>; WG5 <sc22wg5 at open-std.org<mailto:sc22wg5 at open-std.org>>
Subject: [ukfortran] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race conditions allowed in do concurrent?

Hmm... I decided to work through this a bit more thoroughly.

From the syntax definitions:

R902
variable
is designator
or function-reference

R901
designator
is object-name
or array-element
or array-section
or coindexed-named-object
or complex-part-designator
or structure-component
or substring


Ok, so according to the syntax an array element is a variable.

From the terms and definitions:

variable
data entity (3.41) that can be defined (3.48) and redefined during execution of a program

data entity
data object (3.42), result of the evaluation of an expression, or the result of the execution of a function reference

data object
constant, variable, or subobject of a constant

which is circular, and doesn't seem to include individual array elements.

So now the question is which "definition" does the DO CONCURRENT constraint refer to?

From the syntax definitions:

R1129
concurrent-locality
is
[ locality-spec ]...

R1130
locality-spec
is LOCAL ( variable-name-list )
or LOCAL_INIT ( variable-name-list )
or REDUCE ( reduce-operation : variable-name-list )
or SHARED ( variable-name-list )
or DEFAULT ( NONE )

only allows variable-name, not designator, so it's not exactly clear.

The "constraint" appears in normative text, I.e.

If a variable has

which is not hyperlinked and is not in a font indicating reference to the syntax term.

My reading of this is that we have a subtle contradiction between the syntax and normative terms. My guess is that the syntax meaning (i.e. an array element is a variable) is what is intended for the rules here, and thus it's valid to (un)define *different* elements of an array in separate iterations, but not valid to (un)define and reference the same element of an array in separate iterations.

I think it would be worth "fixing" the terms and definitions to eliminate the circular definition and make it consistent with the syntax.

Regards,
Brad

On Tue, 2023-09-12 at 17:37 +0000, Clune, Thomas L. (GSFC-6101) wrote:
“Variable” does not mean what we think it means:     <variable>   <<is>>  <designator> <<or>> <function-reference>

And <designator> includes <array-element>.

But I for one would not mind an explanatory note that clarifies the common use case of array elements in this context.



From:J3 <j3-bounces at mailman.j3-fortran.org<mailto:j3-bounces at mailman.j3-fortran.org>> on behalf of j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Reply-To: j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>
Date: Tuesday, September 12, 2023 at 12:19 PM
To: j3 <j3 at mailman.j3-fortran.org<mailto:j3 at mailman.j3-fortran.org>>, WG5 <sc22wg5 at open-std.org<mailto:sc22wg5 at open-std.org>>
Cc: Brad Richardson <everythingfunctional at protonmail.com<mailto:everythingfunctional at protonmail.com>>
Subject: [EXTERNAL] [BULK] [J3] [SC22WG5.6477] are race conditions allowed in do concurrent?

CAUTION: This email originated from outside of NASA.  Please take care when clicking links or opening attachments.  Use the "Report Message" button to report suspicious messages to the NASA SOC.




Hi Jeff,

Based on " If it is defined or becomes undefined during any iteration, it shall not be referenced, defined, or become undefined during any other iteration.", the provide program is invalid, because `x` becomes defined in more than one iteration.

The way I've heard "definition" applied to arrays is that definition of an element of an array does not constitute definition of the variable, because it is then only partially defined. I.e. an array is only defined once each of its elements has been defined.

My opinion is that the above constraint simply does not adequately describe/is still ambiguous about the case of arrays. I think an interp would be warranted, and we should say that an element of an array should have the same constraint as above if the variable is shared.

Regards,
Brad

On Tue, 2023-09-12 at 14:43 +0000, Jeff Hammond via J3 wrote:
Is this a legal program in Fortran with defined behavior?  If it is illegal or the behavior is undefined, where do we say that?

program main
  integer :: k
  real :: x
  x = 0.0
  do concurrent (k=1:2) shared(x)
    x = real(k)
  end do
  print*,x
end program main

Is that what the following is intended to do?

“If a variable has SHARED locality, appearances of the variable within the DO CONCURRENT construct refer to the variable in the innermost executable construct or scoping unit that includes the DO CONCURRENT construct. If it is defined or becomes undefined during any iteration, it shall not be referenced, defined, or become undefined during any other iteration.”

If so, then I am struggling to apply this to arrays.  When we say a variable has shared locality, is the variable the array or the element?  We can only put array names in SHARED(), but applying the text regarding “to become defined” from the perspective of arrays appears to have interesting consequences.

Thanks,

Jeff

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230919/deb17826/attachment-0001.htm>