From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Wed Sep 20 14:34:34 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 0E46A356A31; Wed, 20 Sep 2023 14:34:34 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mail-ua1-f51.google.com (mail-ua1-f51.google.com [209.85.222.51]) by www.open-std.org (Postfix) with ESMTP id 55504356969 for ; Wed, 20 Sep 2023 14:34:33 +0200 (CEST) Received: by mail-ua1-f51.google.com with SMTP id a1e0cc1a2514c-7a52db1e4bbso2539977241.3 for ; Wed, 20 Sep 2023 05:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lbl-gov.20230601.gappssmtp.com; s=20230601; t=1695213272; x=1695818072; darn=open-std.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=L0DKmTXOTZJoGgKS5wpyQJ1BSNl9JoGb+Yp0KTMFoPc=; b=WeCF/gg6sc1nOQu+eR5bgE92m5r6zypCgy9EHTNkUzvF7q7AaXmogZIuhlWlFreG+6 WFue3zwEBAGt5WAHT/WUA5cBSAQVuudgYTeuTWe2eBPLKkVmDGgqD56iHgIOHnF03kHr t8NrlpeqEH3J+AeoztyaYSJ1GxZRJrEnDFVLUF+FwlELYtq0+dxSz3+xbhWpyMErHMeq vU5CARIl86nTEELJxjgQfF7g3bOeYdWKVtjaELT6Io8cXC8jobS3J0Z+Z0UP02VGhLNa z6xR3rU8j6YXFmzcgM1cO3nNJFar9VEiiLW3GJZCovSIZmsPu3gB6PiD+ED3+F4DL6Ys qtQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695213272; x=1695818072; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=L0DKmTXOTZJoGgKS5wpyQJ1BSNl9JoGb+Yp0KTMFoPc=; b=IUcQ+PZuSonyBzGU3JgEkhPF/5dZSEgcz/RLvD+7xqHXMDMRctBm1X8B/BmyXlBONi FGm0yr1Y3vo/I2OgWXvIGrnmWZI/4JZGDrGTmngt04AaQlnoihWBS6hB7l0Uq5wBu+eS xpijX2fo4lTWOp9qvDpJbTPZp5eWRNFxRR6JinPTUsamfQ+Rz91AcnH1+nqm7BGpZWxP mIw8jQdL8LI068348BGqrMNo3W+2QQHU3zsvIxWRP8pGMF6Dh9/oD1XNix/rMXbxT043 Hf46ENftpLCfCRrCknGkoLz6Y2p8/4P/35kpXIBd6j+yhrVaxt4VycI9XimlwLz/lv0I ei5Q== X-Gm-Message-State: AOJu0YzU8msUyVFksHuHDTStj1TYaA0UvO1CaQc0uikktXfb9nNCrNcB w1R937Hl3sA8sb+2jP7VacW30RqlvyoaUeSZniR1lr2FIFg4bcV9twFOB9oLKm6to64lysvj7pL BZPpBKqUSId+1uNrrlj2XKewtHAhSj6tVbkQe/YvvQXaWvaoQpAmhniKR+V+GSE3emu135JYRle j27NQVar4pGjW3h2C+ X-Google-Smtp-Source: AGHT+IESq7P/boILntoQ1mNOVOzwAFXDcrDFCS4AXGNbg+9qnQiM0AKyNHk0+L3eyh4MVLD3BcuwBJT3kN5Ahfj2yxk= X-Received: by 2002:a1f:c6c1:0:b0:495:ec90:997e with SMTP id w184-20020a1fc6c1000000b00495ec90997emr2577290vkf.7.1695213271566; Wed, 20 Sep 2023 05:34:31 -0700 (PDT) MIME-Version: 1.0 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> <20230920085704.D845D3569F4@www.open-std.org> <20230920093749.0462C3569FD@www.open-std.org> In-Reply-To: From: Damian Rouson Date: Wed, 20 Sep 2023 08:34:20 -0400 Message-ID: Subject: Re: [J3] Do Concurrent with unspecified locality, calling pure procedures To: General J3 interest list Cc: Jeff Hammond , WG5 , Malcolm Cohen Content-Type: multipart/alternative; boundary="000000000000df00290605c99827" Sender: owner-sc22wg5@open-std.org Precedence: bulk --000000000000df00290605c99827 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for pointing this out, Jeff. This is a very important use case for me. Over the past ~3 years, I have evolved toward a pattern of writing libraries in which nearly every procedure in the library is pure with one of the motivations being that this guarantees that nearly every procedure in the library can be called inside `do concurrent`. Such a pattern is especially important if the library code is likely to dominate the runtime of the application that is using the library as I suspect will be the case for some of the libraries that I spend the most time developing lately. Damian On Wed, Sep 20, 2023 at 6:29=E2=80=AFAM Jeff Hammond via J3 < j3@mailman.j3-fortran.org> wrote: > Can we add something about the fact that unspecified locality is nigh > impossible when the code that is executed during the iteration is invisib= le > to the compiler due to a procedure call? > > > > If I take the Peter example and put the loop body in a pure procedure, I > cannot see any way for the compiler to implement what we require there, > which is that elements of T be localized whenever K=3DL (or the entire ar= ray > is localized). > > > The alternative seems to be that procedure calls with arrays will disable > parallelism unless the compile does whole-program analysis, possibly at > link-time, to figure out what is defined or undefined by the procedure. > > > > I don=E2=80=99t expect us to solve this. I=E2=80=99d just like to add th= e commonsense > thing that we all agree on, which is that unspecified locality is a > terrible idea, and that it seems catastrophic in the case of procedure > calls. > > > > module w > > interface > > pure subroutine bar(J,K,L,T,A,B) > > implicit none > > integer, intent(in) :: J, K, L > > real, intent(in) :: A(:) > > real, intent(out) :: B(:) > > real, intent(inout) :: T(:) > > ! the implementation, found elsewhere, does this: > > ! T(K) =3D A(J) > > ! B(J) =3D T(L) > > end subroutine bar > > end interface > > end module w > > > > subroutine foo(N, A, B, T, K, L) > > use w > > implicit none > > integer, intent(in) :: N, K(N), L(N) > > real, intent(in) :: A(N) > > real, intent(out) :: B(N) > > real, intent(inout) :: T(N) > > do concurrent (integer :: J=3D1:N) > > call bar(J,K(J),L(J),T,A,B) > > end do > > end subroutine foo > > > > *From: *J3 on behalf of Jeff Hammond > via J3 > *Date: *Wednesday, 20. September 2023 at 12.37 > *To: *General J3 interest list > *Cc: *Jeff Hammond , WG5 , > Malcolm Cohen > *Subject: *[J3] [SC22WG5.6491] RE: [EXTERNAL] [BULK] Subobject of a > variable > > *External email: Use caution opening links or attachments* > > > > Thanks, I have been slowly coming around to a similar conclusion, which i= s > that Do Concurrent means =E2=80=9Cin any order=E2=80=9D plus =E2=80=9Cuse= r hints that > auto-parallelization is desirable=E2=80=9D, which is to say, Do Concurren= t may only > be mapped to =E2=80=9C!$omp parallel do" conditionally, after the compile= r has > proven that the loop is legal to auto-parallelize. > > > > In this interpretation, Concurrent is still quite powerful, because it > gives the user a way to strongly encourage auto-parallelization, when > compilers may not otherwise do so aggressively because auto-parallelizati= on > all Do loops that are legal to do so with threads is likely to hurt > performance, because thread overhead is nontrivial. This should lead to > high-quality implementations of auto-parallelization (as I know Damian an= d > friends want) and sequential behavior only in pathological cases that mos= t > people aren=E2=80=99t writing. > > > > It may interest some to know that yesterday during the OpenMP meeting, we > decided to settle the problem of =E2=80=9C!$omp loop=E2=80=9D on Do Concu= rrent by adding a > restriction that users must specify the locality of variables that will b= e > written to in more than one iteration. This means that, in the context o= f > OpenMP, Peter=E2=80=99s problematic example becomes erroneous unless the = programmer > adds shared() appropriately, as you and Damian both suggest is the > resolution to this. > > > > Anyways, our implementation likely requires very little change to reflect > this, since Do Concurrent can be implemented with OpenACC =E2=80=9Ckernel= s=E2=80=9D, which > causes the compiler to do auto-parallelization, based on what it can prov= e > is possible. I imagine that Intel will have to do more work, to disable > parallelism when it=E2=80=99s not legal. > > > > Jeff > > > > > > On 20. Sep 2023, at 11.56, Malcolm Cohen via J3 > wrote: > > > > *External email: Use caution opening links or attachments* > > > > Hi Jeff, > > > > The other side of a variable being =E2=80=9Cundefined=E2=80=9D is =E2=80= =9Chaving a specific > value=E2=80=9D. > > > > No-one would expect that having a specific value propagates to subobjects > (the rank or type would be different). > > > > > 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=E2=80=99t. > > > > Rules don=E2=80=99t =E2=80=9Cpropagate=E2=80=9D. Rules are rules. > > > > I do not see anything odd about =E2=80=9CIf I define the whole of array X= in an > iteration, no other iteration can define the whole of array X=E2=80=9D an= d =E2=80=9CIf I > define an element of the array X in an iteration, no other iteration can > define that element of X=E2=80=9D. > > > > Perhaps it might help to think that DO CONCURRENT is not in fact a > variation of OpenMP !$OMP DO. That is not how it came about. DO CONCURREN= T > is two things: > > 1. A reworking of FORALL to remove the plethora of array temps that > FORALL often mandates. > 2. A standardised form of the directive =E2=80=9C!DEC$IVDEP=E2=80=9D (= I probably have > that spelled wrong =E2=80=93 the manuals are in the office.) This dire= ctive > declares that the loop iterations are independent, and that enables va= rious > useful loop optimisations, like software pipelining and so on. > > > > Now, in the =E2=80=9Csimple=E2=80=9D cases (and there are a lot of simple= cases), it can > be easy to parallelise a DO CONCURRENT as originally designed (F2008), vi= z > with everything =E2=80=9Cunspecified locality=E2=80=9D, but although para= llelisability was > a strong consideration, it was not the driving force behind the original > design. > > > > The drawbacks of unspecified locality re parallelisation are what lead to > the introduction of specified locality in F2018. > > > > Seriously, users wanting good performance should not be using unspecified > locality, except perhaps in the simplest of loops. Actually, with my > Software Engineering hat on, I=E2=80=99d say users should not be using un= specified > locality ever, they should tell the compiler **and subsequent > readers/maintainers of the code** what they want explicitly. > > > > And for the compiler, if it cannot work out what the locality of some > variable is, it should just execute the loop serially (in any order). Tha= t > will always give the correct answer, because loop iterations are > independent (well, the user claimed they were, anyway), and do not depend > of what the locality actually is. (If a =E2=80=9Cparallelise DO CONCURREN= T=E2=80=9D option > is active, it might be a good idea to produce a warning when this happens= .) > > > > Anecdote: When I explained DO CONCURRENT to some OpenMP programmers, they > were aghast. =E2=80=9CDo not ever execute it in parallel!=E2=80=9D was th= eir response, with > the explanation =E2=80=9CIf we want a loop executed in parallel we will u= se !$OMP > PARALLEL DO, if the compiler might create threads on any other loop, that > would be excessive threads and would slow down the overall execution due = to > thread contention for resources.=E2=80=9D > > > > 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= =E2=80=99t. > > > > 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=E2=80=99t. > > > > 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=E2=80=99t propaga= te to > subobjects. E.g., if an array is allocatable, it=E2=80=99s elements = are not. > If an array is pointer, it=E2=80=99s elements are not. > > > > And =E2=80=9Cundefinedness=E2=80=9D 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 < > j3@mailman.j3-fortran.org> > *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 undefine= d > 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 become= s > 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=E2=80=99s not written there now, because, like, how co= uld it > possibly be anything else?=E2=80=9D > > > > 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 > 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) =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 becau= se > they are also variables, indeed, portions that can be defined and redefin= ed > separately, and being capable of being defined and redefined makes them > variables. > > > > We could add a NOTE to say that =E2=80=9CA subobject of a variable is a v= ariable, > but a subobject of a constant is not necessarily itself constant, e.g. if > it has a non-constant subscript.=E2=80=9D 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 > *Sent:* Thursday, September 14, 2023 10:25 PM > *To:* General J3 interest list ; '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, subobject= s > 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 l= ocality, > all of its subobjects have SHARED locality=E2=80=9D. It=E2=80=99s not wri= tten 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 writi= ng > =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 delet= ing 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 wh= y 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 ou= r > terms and definitions, down to a more minimal set. If there are =E2=80=9C= useful=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 (o= f =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 > *Sent:* Wednesday, September 13, 2023 3:49 AM > *To:* General J3 interest list ; 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 separat= e > 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: <> > <> > > > > And includes . > > > > But I for one would not mind an explanatory note that clarifies the commo= n > use case of array elements in this context. > > > > > > > > *From:*J3 on behalf of j3 < > j3@mailman.j3-fortran.org> > *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? > > > > *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 a= n > element of an array does not constitute definition of the variable, becau= se > it is then only partially defined. I.e. an array is only defined once eac= h > 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 w= ithin the > DO CONCURRENT construct refer to the variable in the innermost executable > construct or scoping unit that includes the DO CONCURRENT construct. If i= t > 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 in= teresting > consequences. > > > > Thanks, > > > Jeff > > > --000000000000df00290605c99827 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for pointing this out, Jeff.=C2=A0= This is a very important use case for me.=C2=A0 Over the past ~3 years, I = have evolved toward a pattern of writing libraries in which nearly every pr= ocedure in the library is pure with one of the motivations being that this = guarantees that nearly every procedure in the library can be called inside = `do concurrent`.=C2=A0 Such a pattern is especially important if the librar= y code is likely to dominate the runtime of the application that is using t= he library as I suspect will be the case for some of the libraries that I s= pend the most time developing=C2=A0lately.

=
Damian

On Wed, Sep 20, 2023 at 6:29=E2=80=AFAM Jeff Hammond via J3 <= j3@mailman.j3-fortran.org&= gt; wrote:

Can we= add something about the fact that unspecified locality is nigh impossible = when the code that is executed during the iteration is invisible to the com= piler due to a procedure call?

=C2=A0

If I t= ake the Peter example and put the loop body in a pure procedure, I cannot s= ee any way for the compiler to implement what we require there, which is th= at elements of T be localized whenever K=3DL (or the entire array is localized).


The alternative seems to be that procedure calls with arrays will disable p= arallelism unless the compile does whole-program analysis, possibly at link= -time, to figure out what is defined or undefined by the procedure.<= u>

=C2=A0

I don= =E2=80=99t expect us to solve this.=C2=A0 I=E2=80=99d just like to add the = commonsense thing that we all agree on, which is that unspecified locality = is a terrible idea, and that it seems catastrophic in the case of procedure calls.

=C2=A0<= /span>

module w

interface

pure subroutine bar(J= ,K,L,T,A,B)

=C2=A0 implicit none<= u>

=C2=A0 integer, inten= t(in) :: J, K, L

=C2=A0 real, intent(i= n) :: A(:)

=C2=A0 real, intent(o= ut) :: B(:)

=C2=A0 real, intent(i= nout) :: T(:)

=C2=A0 ! the implemen= tation, found elsewher= e, does this:

=C2=A0 ! T(K) =3D A(J= )

=C2=A0 ! B(J) =3D T(L= )

end subroutine bar=

end interface<= u>

end module w

=C2=A0<= /span>

subroutine foo(N, A, = B, T, K, L)

=C2=A0 use w

=C2=A0 implicit none<= u>

=C2=A0 integer, inten= t(in) :: N, K(N), L(N)

=C2=A0 real, intent(i= n) :: A(N)

=C2=A0 real, intent(o= ut) :: B(N)

=C2=A0 real, intent(i= nout) :: T(N)

=C2=A0 do concurrent = (integer :: J=3D1:N)

=C2=A0=C2=A0=C2=A0 ca= ll bar(J,K(J),L(J),T,A,B)

=C2=A0 end do<= u>

end subroutine foo=

=C2=A0<= /span>

From: J3 <j3-bounces@mailman= .j3-fortran.org> on behalf of Jeff Hammond via J3 <j3@mailman.j3-fortran.org<= /a>>
Date: Wednesday, 20. September 2023 at 12.37
To: General J3 interest list <j3@mailman.j3-fortran.org>
Cc: Jeff Hammond <jehammond@nvidia.com>, WG5 <sc22wg5@open-std.org>, Malcolm Cohe= n <malcolm@nag-= j.co.jp>
Subject: [J3] [SC22WG5.6491] RE: [EXTERNAL] [BULK] Subobject of a va= riable

External email: Use caution opening links or atta= chments

=C2=A0<= /span>

Thanks, I have been s= lowly coming around to a similar conclusion, which is that Do Concurrent me= ans =E2=80=9Cin any order=E2=80=9D plus =E2=80=9Cuser hints that auto-paral= lelization is desirable=E2=80=9D, which is to say, Do Concurrent may only be mapped to =E2=80=9C!$omp parallel do" conditionally, after th= e compiler has proven that the loop is legal to auto-parallelize.

=C2=A0<= /span>

In this interpretatio= n, Concurrent is still quite powerful, because it gives the user a way to s= trongly encourage auto-parallelization, when compilers may not otherwise do= so aggressively because auto-parallelization all Do loops that are legal to do so with threads is likely to hurt perfor= mance, because thread overhead is nontrivial.=C2=A0 This should lead to hig= h-quality implementations of auto-parallelization (as I know Damian and fri= ends want) and sequential behavior only in pathological cases that most people aren=E2=80=99t writing. <= /u>

=C2=A0<= /span>

It may interest some = to know that yesterday during the OpenMP meeting, we decided to settle the = problem of =E2=80=9C!$omp loop=E2=80=9D on Do Concurrent by adding a restri= ction that users must specify the locality of variables that will be written to in more than one iteration.=C2=A0 This means that,= in the context of OpenMP, Peter=E2=80=99s problematic example becomes erro= neous unless the programmer adds shared() appropriately, as you and Damian = both suggest is the resolution to this.

=C2=A0<= /span>

Anyways, our implemen= tation likely requires very little change to reflect this, since Do Concurr= ent can be implemented with OpenACC =E2=80=9Ckernels=E2=80=9D, which causes= the compiler to do auto-parallelization, based on what it can prove is possible.=C2=A0 I imagine that Intel will have to do = more work, to disable parallelism when it=E2=80=99s not legal.

=C2=A0<= /span>

Jeff

=C2=A0<= /span>



On 20. Sep 2023, at 1= 1.56, Malcolm Cohen via J3 <j3@mailman.j3-fortran.org> wrote:

=C2=A0<= /span>

External email: Use caution opening links or atta= chments<= /u>

=C2=A0<= /span>

Hi Jeff,

=C2=A0<= u>

The other side of a v= ariable being =E2=80=9Cundefined=E2=80=9D is =E2=80=9Chaving a specific val= ue=E2=80=9D.

=C2=A0<= u>

No-one would expect t= hat having a specific value propagates to subobjects (the rank or type woul= d be different).

=C2=A0<= u>

>=C2=A0It i= s hard for me to understand how I can apply the locality inference rules when the inferred locality propagates, but the rules used for that i= nference don=E2=80=99t.

=C2=A0=

Rules = don=E2=80=99t =E2=80=9Cpropagate=E2=80=9D. Rules are rules.

=C2=A0=

I do n= ot see anything odd about =E2=80=9CIf I define the whole of array X in an i= teration, no other iteration can define the whole of array X=E2=80=9D and = =E2=80=9CIf I define an element of the array X in an iteration, no other iteration can define that element of X=E2=80=9D.=

=C2=A0=

Perhap= s it might help to think that DO CONCURRENT is not in fact a variation of O= penMP !$OMP DO. That is not how it came about. DO CONCURRENT is two things:=

  1. A reworking of FORALL to remove the plethora of array temps that FORALL oft= en mandates.
  2. A standardised form of the directive =E2=80=9C!DEC$IVDEP=E2=80=9D (I probab= ly have that spelled wrong =E2=80=93 the manuals are in the office.) This d= irective declares that the loop iterations are independent, and that enable= s various useful loop optimisations, like software pipelining and so on.

=C2=A0<= u>

Now, in the =E2=80=9C= simple=E2=80=9D cases (and there are a lot of simple cases), it can be easy= to parallelise a DO CONCURRENT as originally designed (F2008), viz with ev= erything =E2=80=9Cunspecified locality=E2=80=9D, but although parallelisabi= lity was a strong consideration, it was not the driving force behind the origin= al design.

=C2=A0<= u>

The drawbacks of unsp= ecified locality re parallelisation are what lead to the introduction of sp= ecified locality in F2018.

=C2=A0<= u>

Seriously, users want= ing good performance should not be using unspecified locality, except perha= ps in the simplest of loops. Actually, with my Software Engineering hat on,= I=E2=80=99d say users should not be using unspecified locality ever, they should tell the compiler *and subsequen= t readers/maintainers of the code* what they want explicitly.=

=C2=A0<= u>

And for the compiler,= if it cannot work out what the locality of some variable is, it should jus= t execute the loop serially (in any order). That will always give the corre= ct answer, because loop iterations are independent (well, the user claimed they were, anyway), and do not dep= end of what the locality actually is. (If a =E2=80=9Cparallelise DO CONCURR= ENT=E2=80=9D option is active, it might be a good idea to produce a warning= when this happens.)

=C2=A0<= u>

Anecdote: When I expl= ained DO CONCURRENT to some OpenMP programmers, they were aghast. =E2=80=9C= Do not ever execute it in parallel!=E2=80=9D was their response, with the e= xplanation =E2=80=9CIf we want a loop executed in parallel we will use !$OMP PARALLEL DO, if the compiler might create threads on any= other loop, that would be excessive threads and would slow down the overal= l execution due to thread contention for resources.=E2=80=9D<= u>

=C2=A0<= u>

Cheers,=

--

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

=C2=A0<= u>

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

=C2=A0

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

=C2=A0=

This b= others me because we use (un)definedness to infer the locality of variables= with unspecified locality.=C2=A0 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 do= n=E2=80=99t.

=C2=A0=

Jeff

=C2=A0<= u>

From:=C2=A0Clune, Thomas L. (GSFC-6101) <thomas.l.clune@nasa.gov>
Date:=C2=A0Tuesday, 19. September 2023 at 16.17
To:=C2=A0General J3 interest list <j3@mailman.j3-fortran.org>
Cc:=C2=A0Jeff Hammond <jehammond@nvidi= a.com>, WG5 <= ;sc22wg5@open-std.org>, Malcolm Cohen <malcolm@nag-j.co.jp>
Subject:=C2= =A0Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a vari= able

External email: Use caution opening links or atta= chments

=C2=A0=

I do n= ot find this situation odd.=C2=A0=C2=A0=C2=A0 Lots of things don=E2=80=99t = propagate to subobjects.=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0E.g., if an array is= allocatable, it=E2=80=99s elements are not.=C2=A0 If an array is pointer, = it=E2=80=99s elements are not.

=C2=A0=

And = =E2=80=9Cundefinedness=E2=80=9D is very much a property of subobjects.=C2= =A0=C2=A0 Indeed, a variable is only defined if all of its subobjects are d= efined.=C2=A0 (I hope I have that right.)

=C2=A0=

  • Tom

=C2=A0=

Fro= m:=C2=A0<= /span>J3 <j3-bounces@mailman.j3-fortran.org> on behalf of j3 <j3@mailman.j3= -fortran.org> Reply-To:=C2= =A0j3 <j3@mailman.j3= -fortran.org> Date:=C2=A0Tuesday, September 19, 2023 at 4:57 AM
To:=C2=A0j3 <j3@mailman.j3-fortra= n.org>
Cc:=C2=A0Jeff Hammond <jehammond@nvidi= a.com>, WG5 <= ;sc22wg5@open-std.org>, Malcolm Cohen <malcolm@nag-j.co.jp>
Subject:=C2= =A0[EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a variable=

=C2=A0=

CAUTION:=C2=A0This email originated fro= m outside of NASA.=C2=A0 Please take care when clicking links or opening attachments.=C2=A0 Use the "Report Message" button to report sus= picious messages to the NASA=C2=A0SOC.




If a variable has unspecified locality,

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

real, = dimension(10) :: A

=C2=A0=

do con= current (integer :: k=3D1:size(A))

=C2=A0= A(k) =3D k

=C2=A0= if (k.eq.1) A(10) =3D 0

end do=

=C2=A0=

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

=C2=A0=

Now su= ppose I make A shared.=C2=A0 Malcolm said all the elements of A are shared = as well "It=E2=80=99s not written there now, because, like, how could = it possibly be anything else?=E2=80=9D

=C2=A0=

real, = dimension(10) :: A

=C2=A0=

do con= current (integer :: k=3D1:size(A)) shared(A)

=C2=A0= A(k) =3D k

=C2=A0= if (k.eq.1) A(10) =3D 0

end do=

=C2=A0=

It is = odd to me that the shared-ness of A propagates to its elements but the unde= fined-ness does not.=C2=A0 Why must I reason about the element-wise behavio= r 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 regard= ing locality?

=C2=A0=

Jeff

=C2=A0=




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

=C2=A0=

External email: Use caution opening links or atta= chments

=C2=A0=

Hi Bra= d,

=C2=A0=

There = is no doubt that subobject includes array elements.

=C2=A0=

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

=C2=A0=

But in= the case of a subobject of a constant, that is often not constant. E.g.

=C2=A0= =C2=A0 INTEGER,PARAMETER :: x(10) =3D [ 1,2,3,4,5,6,7,8,9,10 ]

=C2=A0= =C2=A0 READ *,I

=C2=A0= =C2=A0PRINT *,x(I)=C2=A0

=C2=A0=

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

=C2=A0=

That i= s what those words are there for. They are not intended to imply that subob= jects 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 define= d and redefined makes them variables.

=C2=A0=

We cou= ld add a NOTE to say that =E2=80=9CA 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.=E2=80=9D Not sure it is really worth it though, at least, not until we decide what to do with o= ur overly-large set of terms.

=C2=A0=

Cheers= ,

--

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

=C2=A0=

Fro= m:=C2=A0Brad Richardson <everythingfunctional@pr= otonmail.com>=C2=A0
Sent:=C2= =A0Thursday, September 14, 2023 10:25 PM
To:=C2=A0= General J3 interest list <j3@mailman.j3-fortran.org>; 'WG5' <= sc22wg5@open-std.org>
Subject:= =C2=A0[ukfortran] [SC22WG5.6484] [J3] RE: [EXTERNAL] [BULK] are race= conditions allowed in do concurrent?

=C2=A0=

Hi Mal= colm,

=C2=A0=

> &= gt;variable/data entity/data object

> &= gt;[are]=C2=A0circular, and doesn't seem to include individual array elements

=C2=A0=

> Y= es it does, see 3.138 subobject.

=C2=A0=

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

=C2=A0=

subobj= ect of a constant

=C2=A0=

so the= edit would be to change it to

=C2=A0=

subobj= ect of a variable or constant

=C2=A0=

I don&= #39;t think the circularity is causing too much confusion, so I don't s= ee 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.

=C2=A0=

Regard= s,

Brad

=C2=A0=

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

Hi Bra= d,

=C2=A0=

There = is no contradiction, subtle or otherwise, here.

=C2=A0=

Locali= ty-specs are only for named variables. However, as noted, subobjects of var= iables are also variables.

=C2=A0=

>=C2=A0The w= ay I've heard "definition" applied to arrays is that definiti= on of an element of an array does not constitute definition of the variable= ,

=C2=A0=

Correc= t (except in the trivial case of an array with a single element). This is a= ll spelled out explicitly: defining every =E2=80=9Cpart=E2=80=9D of a multi= -part variable defines the variable.

=C2=A0=

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

=C2=A0=

E.g. i= t 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 writ= ten there now, because, like, how could it possibly be anything else? There is nothing else it could be.=C2=A0 But making it explicit woul= d lead naturally into writing =E2=80=9CIf a variable with SHARED locality i= s defined=E2=80=A6=E2=80=9D instead of the current =E2=80=9CIf it is define= d=E2=80=A6=E2=80=9D.

=C2=A0=

>va= riable/data entity/data object

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

=C2=A0=

Yes it= does, see 3.138 subobject.

=C2=A0=

The ci= rcularity is unfortunate, but they are all reasonably worded for comprehens= ibility (not for trail-following). So it=E2=80=99s either deleting one of t= hem (ugh) or rewording one to break the circle without making it hard to understand (it=E2=80=99s not obvious exactly wha= t to do here, which is why it is still like this).

=C2=A0=

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

=C2=A0=

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.

=C2=A0=

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 be= tter not to call them =E2=80=9Cterms=E2=80=9D!).

=C2=A0=

Cheers= ,

--

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

=C2=A0=

Fro= m:=C2=A0Brad Richardson <everythingfunctional@pr= otonmail.com>=C2=A0
Sent:=C2= =A0Wednesday, September 13, 2023 3:49 AM
To:=C2=A0= General J3 interest list <j3@mailman.j3-fortran.org>; WG5 <<= span lang=3D"EN-US" style=3D"font-size:11pt;color:rgb(5,99,193)">sc22wg5@op= en-std.org>
Subject:= =C2=A0[ukfortran] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race con= ditions allowed in do concurrent?

=C2=A0=

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

=C2=A0=

From t= he syntax definitions:

=C2=A0=

R902

variab= le

is des= ignator

or fun= ction-reference

=C2=A0=

R901

design= ator

is obj= ect-name

or arr= ay-element

or arr= ay-section

or coi= ndexed-named-object

or com= plex-part-designator

or str= ucture-component

or sub= string

=C2=A0=

=C2=A0=

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

=C2=A0=

From t= he terms and definitions:

=C2=A0=

variab= le

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

=C2=A0=

data e= ntity

data o= bject (3.42), result of the evaluation of an expression, or the result of t= he execution of a function reference

=C2=A0=

data o= bject

consta= nt, variable, or subobject of a constant

=C2=A0=

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

=C2=A0=

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

=C2=A0=

From t= he syntax definitions:

=C2=A0=

R1129<= /span>

concur= rent-locality

is

[ loca= lity-spec ]...

=C2=A0=

R1130<= /span>

locali= ty-spec

is LOC= AL ( variable-name-list )

or LOC= AL_INIT ( variable-name-list )

or RED= UCE ( reduce-operation : variable-name-list )

or SHA= RED ( variable-name-list )

or DEF= AULT ( NONE )

=C2=A0=

only a= llows variable-name, not designator, so it's not exactly clear.<= u>

=C2=A0=

The &q= uot;constraint" appears in normative text, I.e.

=C2=A0=

If a v= ariable has

=C2=A0=

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

=C2=A0=

My rea= ding 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* elem= ents of an array in separate iterations, but not valid to (un)define and re= ference the same element of an array in separate iterations.<= u>

=C2=A0=

I thin= k it would be worth "fixing" the terms and definitions to elimina= te the circular definition and make it consistent with the syntax.

=C2=A0=

Regard= s,

Brad

=C2=A0=

On Tue= , 2023-09-12 at 17:37 +0000, Clune, Thomas L. (GSFC-6101) wrote:<= /u>

=E2=80= =9CVariable=E2=80=9D does not mean what we think it means:=C2=A0=C2=A0=C2= =A0=C2=A0 <variable>=C2=A0 =C2=A0<<is>>=C2=A0 <designa= tor> <<or>> <function-reference><= /p>

=C2=A0=

And &l= t;designator> includes <array-element>.

=C2=A0=

But I = for one would not mind an explanatory note that clarifies the common use ca= se of array elements in this context.=C2=A0

=C2=A0=

=C2=A0=

=C2=A0=

Fro= m:J3 <j3-bounces@mail= man.j3-fortran.org= > on behalf of j3 <j3@mailman.j3-fortran.org>
Reply-To:=C2= =A0j3 <j3@mailman.j3-fortran.org>
Date:=C2=A0Tuesday, September 12, 2023 at 12:19 PM
To:=C2=A0j3 <= j3@mailman.j3-fortran.org>, WG5 <sc22wg5@open-std.org>
Cc:=C2=A0Brad Richardson <everythingfunctional@protonmail.com>
Subject:=C2= =A0[EXTERNAL] [BULK] [J3] [SC22WG5.6477] are race conditions all= owed in do concurrent?

=C2=A0=

CAUTION:=C2=A0This email originated fro= m outside of NASA.=C2=A0 Please take care when clicking links or opening attachments.=C2=A0 Use the "Report Message" button to report sus= picious messages to the NASA=C2=A0SOC.







Hi Jef= f,

=C2=A0=

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

=C2=A0=

The wa= y I've heard "definition" applied to arrays is that definitio= n 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.

=C2=A0=

My opi= nion is that the above constraint simply does not adequately describe/is st= ill ambiguous about the case of arrays. I think an interp would be warrante= d, and we should say that an element of an array should have the same constraint as above if the variable is sh= ared.

=C2=A0=

Regard= s,

Brad

=C2=A0=

On Tue= , 2023-09-12 at 14:43 +0000, Jeff Hammond via J3 wrote:

Is thi= s a legal program in Fortran with defined behavior?=C2=A0 If it is illegal = or the behavior is undefined, where do we say that?

=C2=A0=

progra= m main

=C2=A0= integer :: k

=C2=A0= real :: x

=C2=A0= x =3D 0.0

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

=C2=A0= =C2=A0=C2=A0 x =3D real(k)

=C2=A0= end do

=C2=A0= print*,x

end pr= ogram main

=C2=A0=

Is tha= t what the following is intended to do?

=C2=A0=

=E2=80= =9CIf a variable has SHARED locality, appearances of the variable within th= e 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

=C2=A0=

If so,= then I am struggling to apply this to arrays.=C2=A0 When we say a variable= has shared locality, is the variable the array or the element?=C2=A0 We ca= n only put array names in SHARED(), but applying the text regarding =E2=80=9Cto become defined=E2=80=9D from the perspectiv= e of arrays appears to have interesting consequences.<= /p>

=C2=A0=

Thanks= ,


Jeff

=C2=A0<= /span>

--000000000000df00290605c99827--