From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Thu Sep 14 07:11:37 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 5FF0A3569E9; Thu, 14 Sep 2023 07:11:37 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 398 seconds by postgrey-1.34 at www5.open-std.org; Thu, 14 Sep 2023 07:11:32 CEST Received: from nag-j.co.jp (bvdeuz19.secure.ne.jp [180.222.80.19]) by www.open-std.org (Postfix) with SMTP id 044A53569C2 for ; Thu, 14 Sep 2023 07:11:31 +0200 (CEST) Received: (qmail 76246 invoked from network); 14 Sep 2023 14:04:47 +0900 Received: from unknown (HELO Maru10) (218.42.159.105) by 0 with SMTP; 14 Sep 2023 14:04:47 +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> In-Reply-To: <20230912184902.A227F35699F@www.open-std.org> Subject: RE: [ukfortran] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race conditions allowed in do concurrent? Date: Thu, 14 Sep 2023 14:04:49 +0900 Message-ID: <002f01d9e6c8$fcd845a0$f688d0e0$@nag-j.co.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01D9E714.6CC25EA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQG/qXZQcGIQLpZ1F3Ca3tHLE/EEbAFGgQaEAuD8HXAB7pdlIbAdh2GQ Content-Language: ja Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_0030_01D9E714.6CC25EA0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Brad, =20 There is no contradiction, subtle or otherwise, here. =20 Locality-specs are only for named variables. However, as noted, = subobjects of variables are also variables. =20 > 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, =20 Correct (except in the trivial case of an array with a single element). = This is all spelled out explicitly: defining every = =E2=80=9Cpart=E2=80=9D of a multi-part variable defines the variable. =20 I can see some potential wording improvements for the next revision, but = nothing that rises to the level of a defect. =20 E.g. it may be better to mention that =E2=80=9Cif a variable has SHARED = locality, all of its subobjects have SHARED locality=E2=80=9D. = It=E2=80=99s 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 =E2=80=9CIf a variable with = SHARED locality is defined=E2=80=A6=E2=80=9D instead of the current = =E2=80=9CIf it is defined=E2=80=A6=E2=80=9D. =20 >variable/data entity/data object >[are] circular, and doesn't seem to include individual array elements =20 Yes it does, see 3.138 subobject. =20 The circularity is unfortunate, but they are all reasonably worded for = comprehensibility (not for trail-following). So it=E2=80=99s either = deleting one of them (ugh) or rewording one to break the circle without = making it hard to understand (it=E2=80=99s not obvious exactly what to = do here, which is why it is still like this). =20 If it were a glossary of terms, instead of a list of definitions, there = would be no problem with circularity, right? =20 Anyway, I agree it would be good to fix it as long as it doesn=E2=80=99t = make any individual term hard to understand. =20 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 = =E2=80=9Cuseful=E2=80=9D terms that do not lend themselves to trivial = drop-in replacement, and I think there are, we could consider adding a = =E2=80=9CGlossary=E2=80=9D (of =E2=80=9Cuseful terms=E2=80=9D, but = probably better not to call them =E2=80=9Cterms=E2=80=9D!).=20 =20 Cheers, --=20 ..............Malcolm Cohen, NAG Oxford/Tokyo. =20 From: Brad Richardson =20 Sent: Wednesday, September 13, 2023 3:49 AM To: General J3 interest list ; WG5 = Subject: [ukfortran] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race = conditions allowed in do concurrent? =20 Hmm... I decided to work through this a bit more thoroughly. =20 From the syntax definitions: =20 R902 variable is designator or function-reference =20 R901 designator is object-name or array-element or array-section or coindexed-named-object or complex-part-designator or structure-component or substring =20 =20 Ok, so according to the syntax an array element is a variable. =20 From the terms and definitions: =20 variable data entity (3.41) that can be defined (3.48) and redefined during = execution of a program =20 data entity data object (3.42), result of the evaluation of an expression, or the = result of the execution of a function reference =20 data object constant, variable, or subobject of a constant =20 which is circular, and doesn't seem to include individual array = elements. =20 So now the question is which "definition" does the DO CONCURRENT = constraint refer to? =20 From the syntax definitions: =20 R1129 concurrent-locality is [ locality-spec ]... =20 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 ) =20 only allows variable-name, not designator, so it's not exactly clear. =20 The "constraint" appears in normative text, I.e. =20 If a variable has =20 which is not hyperlinked and is not in a font indicating reference to = the syntax term. =20 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. =20 I think it would be worth "fixing" the terms and definitions to = eliminate the circular definition and make it consistent with the = syntax. =20 Regards, Brad =20 On Tue, 2023-09-12 at 17:37 +0000, Clune, Thomas L. (GSFC-6101) wrote: =E2=80=9CVariable=E2=80=9D does not mean what we think it means: = <> <> =20 And includes . =20 But I for one would not mind an explanatory note that clarifies the = common use case of array elements in this context.=20 =20 =20 =20 From:J3 > on behalf of j3 = > Reply-To: j3 > Date: Tuesday, September 12, 2023 at 12:19 PM To: j3 >, = WG5 > Cc: Brad Richardson > Subject: [EXTERNAL] [BULK] [J3] [SC22WG5.6477] are race conditions = allowed in do concurrent? =20 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.=20 Hi Jeff, =20 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. =20 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. =20 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. =20 Regards, Brad =20 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? =20 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 =20 Is that what the following is intended to do? =20 =E2=80=9CIf 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.=E2=80=9D =20 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 = =E2=80=9Cto become defined=E2=80=9D from the perspective of arrays = appears to have interesting consequences. =20 Thanks, Jeff =20 =20 =20 ------=_NextPart_000_0030_01D9E714.6CC25EA0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

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 =E2=80=9Cpart=E2=80=9D 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 =E2=80=9Cif a variable has SHARED = locality, all of its subobjects have SHARED locality=E2=80=9D. = It=E2=80=99s not written there now, because, like, how could it possibly = be anything else? There is nothing else it could be. =C2=A0But making it = explicit would lead naturally into writing =E2=80=9CIf a variable with = SHARED locality is defined=E2=80=A6=E2=80=9D instead of the current = =E2=80=9CIf it is defined=E2=80=A6=E2=80=9D.

 

>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=E2=80=99s either = deleting one of them (ugh) or rewording one to break the circle without = making it hard to understand (it=E2=80=99s 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=E2=80=99t 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 = =E2=80=9Cuseful=E2=80=9D terms that do not lend themselves to trivial = drop-in replacement, and I think there are, we could consider adding a = =E2=80=9CGlossary=E2=80=9D (of =E2=80=9Cuseful terms=E2=80=9D, but = probably better not to call them =E2=80=9Cterms=E2=80=9D!). =

 

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

<= p class=3DMsoNormal>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:

=E2=80=9CVariable=E2=80=9D 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-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 12, 2023 at 12:19 PM
To: = j3 <j3@mailman.j3-fortran.org&g= t;, WG5 <sc22wg5@open-std.org>
C= c: 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 =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?

 

=E2=80=9CIf 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.=E2=80=9D

 

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 =E2=80=9Cto become = defined=E2=80=9D from the perspective of arrays appears to have = interesting consequences.

 

Thanks,


Jeff

 

 

 

------=_NextPart_000_0030_01D9E714.6CC25EA0--