From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Wed Sep 20 11:00:18 2023 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id E1C7A3569F4; Wed, 20 Sep 2023 11:00:17 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (bvdeuz19.secure.ne.jp [180.222.80.19]) by www.open-std.org (Postfix) with SMTP id 71EB3356973 for ; Wed, 20 Sep 2023 11:00:14 +0200 (CEST) Received: (qmail 83203 invoked from network); 20 Sep 2023 18:00:13 +0900 Received: from unknown (HELO Maru10) (218.42.159.105) by 0 with SMTP; 20 Sep 2023 18:00:13 +0900 From: "Malcolm Cohen" To: "'WG5'" References: <20230912161937.ED0F6356986@www.open-std.org> <493F5A4F-8746-4CA4-ACF7-554B71168255@nasa.gov> <20230912184902.A227F35699F@www.open-std.org> <20230914051137.8F0F93569EF@www.open-std.org> <20230914132511.A9155356742@www.open-std.org> <20230919074924.5A64A356969@www.open-std.org> <20230919085702.1ECCF3569C0@www.open-std.org> <73963378-8AB0-447B-8BA0-EC90F07B0FEF@nasa.gov> In-Reply-To: Subject: RE: [J3] [SC22WG5.6488] [EXTERNAL] [BULK] Subobject of a variable Date: Wed, 20 Sep 2023 18:00:14 +0900 Message-ID: <02d301d9eba0$de4a5b50$9adf11f0$@nag-j.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D4_01D9EBEC.4E36BE40" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG/qXZQcGIQLpZ1F3Ca3tHLE/EEbAFGgQaEAuD8HXAB7pdlIQFRoAeAAhuw4kIC1WjZxwJ3QBx3AbrjyQ0B8n/94a/EAnYA Content-Language: ja Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_02D4_01D9EBEC.4E36BE40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit One last thing. "unspecified locality" is not "inferred locality". Unspecified locality is its own thing, just as "unspecified intent" is also its own thing. It is not always the case that unspecified locality acts as if it were one of the specified possibilities. Yes, it is horrible. That's why we added specified locality. Unspecified is just there for (a) the easy cases, and (b) to maintain backward compatibility. Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. From: J3 On Behalf Of Jeff Hammond via J3 Sent: Tuesday, September 19, 2023 10:59 PM To: Clune, Thomas L. (GSFC-6101) ; General J3 interest list Cc: Jeff Hammond ; WG5 ; Malcolm Cohen Subject: [J3] [SC22WG5.6488] [EXTERNAL] [BULK] Subobject of a variable Okay, but we are saying that, in the context of do concurrent, locality obviously propagates to subobjects, but (un)definedness obviously doesn't. This bothers me because we use (un)definedness to infer the locality of variables with unspecified locality. It is hard for me to understand how I can apply the locality inference rules when the inferred locality propagates, but the rules used for that inference don't. Jeff From: Clune, Thomas L. (GSFC-6101) > Date: Tuesday, 19. September 2023 at 16.17 To: General J3 interest list > Cc: Jeff Hammond >, WG5 >, Malcolm Cohen > Subject: Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a variable External email: Use caution opening links or attachments I do not find this situation odd. Lots of things don't propagate to subobjects. E.g., if an array is allocatable, it's elements are not. If an array is pointer, it's elements are not. And "undefinedness" is very much a property of subobjects. Indeed, a variable is only defined if all of its subobjects are defined. (I hope I have that right.) * Tom From: J3 > on behalf of j3 > Reply-To: j3 > Date: Tuesday, September 19, 2023 at 4:57 AM To: j3 > Cc: Jeff Hammond >, WG5 >, Malcolm Cohen > Subject: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a variable 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. 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 > 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@protonmail.com> Sent: Thursday, September 14, 2023 10:25 PM To: General J3 interest list < j3@mailman.j3-fortran.org>; 'WG5' < sc22wg5@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@protonmail.com> Sent: Wednesday, September 13, 2023 3:49 AM To: General J3 interest list < j3@mailman.j3-fortran.org>; WG5 < sc22wg5@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: <> <> And includes . 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@mailman.j3-fortran.org> on behalf of j3 < j3@mailman.j3-fortran.org> Reply-To: j3 < j3@mailman.j3-fortran.org> Date: Tuesday, September 12, 2023 at 12:19 PM To: j3 < j3@mailman.j3-fortran.org>, WG5 < sc22wg5@open-std.org> Cc: Brad Richardson < everythingfunctional@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 ------=_NextPart_000_02D4_01D9EBEC.4E36BE40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One last thing.

 

“unspecified = locality” is not “inferred locality”. Unspecified = locality is its own thing, just as “unspecified intent” is = also its own thing. It is not always the case that unspecified locality = acts as if it were one of the specified = possibilities.

 

Yes, it is horrible. = That’s why we added specified locality. Unspecified is just there = for (a) the easy cases, and (b) to maintain backward = compatibility.

 

Cheers,

--

..............Malcolm Cohen, NAG = Oxford/Tokyo.

 

From: J3 <j3-bounces@mailman.j3-fortran.org> = On Behalf Of Jeff Hammond via J3
Sent: Tuesday, = September 19, 2023 10:59 PM
To: Clune, Thomas L. (GSFC-6101) = <thomas.l.clune@nasa.gov>; General J3 interest list = <j3@mailman.j3-fortran.org>
Cc: Jeff Hammond = <jehammond@nvidia.com>; WG5 <sc22wg5@open-std.org>; Malcolm = Cohen <malcolm@nag-j.co.jp>
Subject: [J3] [SC22WG5.6488] = [EXTERNAL] [BULK] Subobject of a = variable

 

Okay, but we are saying that, in = the context of do concurrent, locality obviously propagates to = subobjects, but (un)definedness obviously = doesn’t.

 

This = bothers me because we use (un)definedness to infer the locality of = variables with unspecified locality.  It is hard for me to = understand how I can apply the locality inference rules when the = inferred locality propagates, but the rules used for that inference = don’t.

 

Jeff

 

From: = Clune, Thomas L. (GSFC-6101) = <thomas.l.clune@nasa.gov>Date: Tuesday, 19. September 2023 at 16.17
To: = General J3 interest list <j3@mailman.j3-fortran.org&g= t;
Cc: Jeff Hammond <jehammond@nvidia.com>, WG5 = <sc22wg5@open-std.org>, = Malcolm Cohen <malcolm@nag-j.co.jp>
Sub= ject: Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a = variable

Ex= ternal email: Use caution opening links or attachments =

 

I do not = find this situation odd.    Lots of things don’t = propagate to subobjects.      E.g., if an array = is allocatable, it’s elements are not.  If an array is = pointer, it’s elements are not.

 

And = “undefinedness” is very much a property of = subobjects.   Indeed, a variable is only defined if all of its = subobjects are defined.  (I hope I have that = right.)

 

  • Tom

 

From: = J3 = <j3-bounces@mailman.j3-f= ortran.org> on behalf of j3 <j3@mailman.j3-fortran.org&g= t;
Reply-To: j3 <j3@mailman.j3-fortran.org&g= t;
Date: Tuesday, September 19, 2023 at 4:57 AM
To: = j3 <j3@mailman.j3-fortran.org&g= t;
Cc: Jeff Hammond <jehammond@nvidia.com>, WG5 = <sc22wg5@open-std.org>, = Malcolm Cohen <malcolm@nag-j.co.jp>
Sub= ject: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a = variable

 

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



<= div>

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=3D1:size(A))

  A(k) =3D = k

  if (k.eq.1) A(10) =3D = 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=3D1:size(A)) = shared(A)

  A(k) =3D = k

  if (k.eq.1) A(10) =3D = 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@mailman.j3-fortran.org&g= t; wrote:

 

Ex= ternal 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) =3D [ = 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@protonmail.com>= ; 
Sent: Thursday, September 14, 2023 = 10:25 PM
To: General J3 interest list = <j3@mailman.j3-fortran.org>; 'WG5' = <sc22wg5@open-std.org>
Subject= : [ukfortran] = [SC22WG5.6484] [J3] RE: [EXTERNAL] [BULK] are race conditions allowed in = do concurrent?

 

Hi = Malcolm,

 

<= div>

> >variable/data entity/data = object

> >[are] circular, and doesn't seem to = include individual array = elements

 

<= div>

> Yes it does, see 3.138 = subobject.

 

<= div>

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

 

<= div>

subobject of a = constant

 

<= div>

so the edit would be to change it = to

 

<= div>

subobject of a variable or = constant

 

<= div>

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.

 

<= div>

Regards,

Brad

 

<= div>

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@protonmail.com>= ; 
Sent: Wednesday, September 13, 2023 = 3:49 AM
To: General J3 interest list = <j3@mailman.j3-fortran.org>; WG5 = <sc22wg5@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.

 

<= div>

From the syntax = definitions:

 

<= div>

R902

variable

is = designator

or = function-reference

 

<= div>

R901

designator

is = object-name

or = array-element

or = array-section

or = coindexed-named-object

or = complex-part-designator

or = structure-component

or = substring

 

<= div>

 

<= div>

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

 

<= div>

From the terms and = definitions:

 

<= div>

variable

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

 

<= div>

data = entity

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

 

<= div>

data = object

constant, variable, or subobject of a = constant

 

<= div>

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

 

<= div>

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

 

<= div>

From the syntax = definitions:

 

<= div>

R1129

concurrent-locality

is

=

[ locality-spec = ]...

 

<= div>

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

 

<= div>

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

 

<= div>

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

 

<= div>

If a variable = has

 

<= div>

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

 

<= div>

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.

 

<= div>

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

 

<= div>

Regards,

Brad

 

<= div>

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@mailman.j3-fortran.org> = on behalf of j3 <j3@mailman.j3-fortran.org>
Re= ply-To: j3 <j3@mailman.j3-fortran.org>
Da= te: Tuesday, = September 12, 2023 at 12:19 PM
To: j3 <j3@mailman.j3-fortran.org>, WG5 = <sc22wg5@open-std.org>
Cc: Brad Richardson <everythingfunctional@protonmail.com>= ;
Subject: [EXTERNAL] [BULK] [J3] = [SC22WG5.6477] are race conditions allowed in do concurrent?

 

<= table class=3DMsoNormalTable border=3D1 cellspacing=3D0 cellpadding=3D0 = align=3Dleft width=3D"100%" style=3D'width:100.0%;border:solid black = 1.5pt'>

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,

 

<= div style=3D'margin-left:36.0pt'>

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.

 

<= div style=3D'margin-left:36.0pt'>

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.

 

<= div style=3D'margin-left:36.0pt'>

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.

 

<= div style=3D'margin-left:36.0pt'>

Regards,

Brad

 

<= div style=3D'margin-left:36.0pt'>

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 =3D 0.0

  do concurrent (k=3D1:2) = shared(x)

    x =3D 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

 

= ------=_NextPart_000_02D4_01D9EBEC.4E36BE40--