From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Wed Sep 20 12:29:16 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 E69A5356969; Wed, 20 Sep 2023 12:29:15 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2066.outbound.protection.outlook.com [40.107.237.66]) by www.open-std.org (Postfix) with ESMTP id 0E2AD3566AA for ; Wed, 20 Sep 2023 12:29:13 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AyfrWum709MhQ44zQFvi/o7zN+eJ0CzI5FsEAzn933lBE1VDdKwBVn2U9N+65lulXC7FMU353ttf90pPw3m5uj8kWqbUkarhjOqa/vAcyUJus2IE7kXKbHJLdGVVrIvr3Ukhb8iGXv1VhcIfolpTYHoNEObnkZHz/9A8WWkj0kinlgPD0JfLXmQkWj3pC4x/b4WAxDAu70ACDJM8t22vg1/zBfi3ScCDFrax75csC+venHyFc5/VgRL7dGQD9a2cBARsZtTlQvw8oDb/0aKJY13XXhZTe1cjXQ4sFlVh+vORDPWQOSFuw54w9ce7mn6MPMTAeN4nX+3D4jA9/8XFsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=QVQ93QnLV03BGTHLyeCfpnnDlRD/skEBB7MFaMwpgGA=; b=j9CHLhf+b0iv1NzLDlnYyGE1lsq/25S9RwE1DKi0ZNwG6yiouxT+WIxIG5soKVI8U4exX1tVafJklez54N3ySnnr9ftDmz0adhGZpKbVFItMR++L7JlBo91zUCkqSXnJz+JWGVu22FSJh7ipBOD9aZXWsryjFMwfodACzPj8yiNfxQB6bw41b86XbJ4V4H2gXhCq3wQL2RH+vgQgiHSL+3VGIr7MujcjeYDAS4bdjkUrOTTLX4Ga6vmMU1Dw8F5MqWAnwQfXPyDqkbIEIjjqVIsWwH2SCO21w20MpfauryF1g9Nuy+KY0faC6AnDcd6/r07TaSQ9Gzny8NSMJg4cPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QVQ93QnLV03BGTHLyeCfpnnDlRD/skEBB7MFaMwpgGA=; b=eByyUtfKizCdOir5GsFN5InKpnIQOuhfRB4n5BFWJS1foGonjEzvCu46tZI5u5XH7t/dyfHDp8CAStJRdgeqmjZtr/v5DTx0xI7WAfDFs53G+166OzZXaO+YNMW2XR6VMARK2RexBz12Tl4BXHoDUenXJ2nvWOar9MXc5q+2I01HMa8kmMssjgRU4Ofo7cvie44Kjk/jX06F4rWxjSWZBvE6UhZ0NGIYqJaVLwgS/REnF4kNpdjt2RVIQCBrPLszC05HCWsbiS9zWkGxWOf6TA8KZyAW12E0y8oLOwBONR1baCucCzqQ4ugNgdkb+xHE0zy4xDJg42R2Bm60kfoIcw== Received: from DM6PR12MB3130.namprd12.prod.outlook.com (2603:10b6:5:11b::16) by BY5PR12MB4305.namprd12.prod.outlook.com (2603:10b6:a03:213::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.22; Wed, 20 Sep 2023 10:28:53 +0000 Received: from DM6PR12MB3130.namprd12.prod.outlook.com ([fe80::59af:3a04:c24f:8191]) by DM6PR12MB3130.namprd12.prod.outlook.com ([fe80::59af:3a04:c24f:8191%5]) with mapi id 15.20.6792.026; Wed, 20 Sep 2023 10:28:53 +0000 From: Jeff Hammond To: General J3 interest list CC: WG5 , Malcolm Cohen Subject: Do Concurrent with unspecified locality, calling pure procedures Thread-Topic: Do Concurrent with unspecified locality, calling pure procedures Thread-Index: AQHZ661A5XbzNQWwhkGiRHt1eHLsWg== Date: Wed, 20 Sep 2023 10:28:52 +0000 Message-ID: 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: <20230920093749.0462C3569FD@www.open-std.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nvidia.com; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: DM6PR12MB3130:EE_|BY5PR12MB4305:EE_ x-ms-office365-filtering-correlation-id: 2e2970a1-38ca-4913-f09f-08dbb9c46315 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: R5KLtfrEP34Kjsh6Im1uRpvhlUvbQ6XSQAIW+B85jgjjM0TtPb+aGzFeH/vVkwnLum5LIU1pnhBb0KHdn4V5AGRsSslmRZhVebG/And0OsVtRiJOp6UfFHUH4XwzhNLF4YpKoTIKZB+58Q8tYZwSnIk6S38tMpebBcCce8vKv6TE0kAu+8xcWIP1XlIFkSCrn6trdI50A7MWJcyGIpEPU00Vg/4ibfSSVbDJiZj3lappnuQJg6dDl9lRASVGKNIWC5YMqn4cpm0VsAmDuNVoMI897n0Wd9Lbq0fRv4wiaDA6KbRicrQpo4kSGYem19z/NENT5RTG3UJkuKRd1TyoFuagIeBBEsG7sL+geHstgiFxBqX+6KRmstscaEGdQfj7OqAQ1dIYFk89PA+zPBvhyQK0Xl3ef3cQoLj6/2UnMGAoQh7+cTZ4dDp2DBWXA6WDmR6aPvMf+n2HLMuWfnTioBoAGz5UScoVcLpGC26PXck+nliD1gZFW/xqeiaDElp9IahTaETbkPbW3XlgPJBUgXuJkfBkngrMxOgik3S70Hmoz7j5hcUp7E5rVotnW3p8oRVGdARNnr7OvIsP5uqh3/m7TTrVqDxNfXshOBb98HerZDr9LH/srArlIUW8E0l7 x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:DM6PR12MB3130.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230031)(366004)(39860400002)(136003)(396003)(376002)(346002)(451199024)(1800799009)(186009)(76116006)(30864003)(478600001)(66476007)(41300700001)(83380400001)(55016003)(5660300002)(52536014)(66946007)(71200400001)(2906002)(6916009)(66446008)(8936002)(54906003)(8676002)(316002)(64756008)(4326008)(66556008)(53546011)(6506007)(7696005)(9686003)(26005)(38070700005)(33656002)(86362001)(122000001)(38100700002)(579004)(559001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?oYGAYVyKB3KACiFuHs91FGTJyqeDP4ZtsUbmMhD2afPEKQeQbqRhl4RM?= =?Windows-1252?Q?BwH4IZDXhVmLbl64amlRXrxaL3ykDBbKkXuYmgyLAuhjlJg0/WX0THIp?= =?Windows-1252?Q?0UsMFnMVfrokXgchdqbP48z1IvghwQ6NyHdvx0XiOI26GUCEWikRFIYA?= =?Windows-1252?Q?zfeYKdNPerKgAAEE6Ohcx1tvMm1Zobzdsp3E/8883OmiKcc4eXgguBRw?= =?Windows-1252?Q?+lswH9JcL+imI6MAJ32DuujC9IwXd3Vpfe//GhquHndRU8kArDy+Bo7f?= =?Windows-1252?Q?ZfHy5HFm0Any8px5qCVah/NrCrxRuG59D5wSI4/1u/UY1UQOaLbG3frt?= =?Windows-1252?Q?V4pPIx7Z4pxTSzpqVw2s+9yilbh1H9aduXl659lfIfpXiDdRiKRG0upy?= =?Windows-1252?Q?nveVdlVsmuzdqKPeS0gW9DMe/szpGSkxxhhO8F4z6e54LXpLRGshPmX3?= =?Windows-1252?Q?habMFfwCBszU6Z6cUbt+heni2G0Q/e/HALrQEGtsdbUCLm8c1WtKewPk?= =?Windows-1252?Q?eVgiS26cIEhfppW6f21BvjuLRCFaVuxcPPW2LvYv74jQh0A9wZwrmRdi?= =?Windows-1252?Q?U/i1Iu6Ii3yNtPDbCq7HPbgOdpIMf7rUwKS2r6Mrr4ynwgZo5Ix40SkV?= =?Windows-1252?Q?T+kHja2jzCoaCd3eg4v1Js06AbNM2GiVv5eaGfChpR5tHLK2TCo5VVWP?= =?Windows-1252?Q?Z7jP8+T5As5NsrhKFdhs/JRyLkTHxgbkr23Y3UhNIPcWL43g9ZvPOS9o?= =?Windows-1252?Q?SOhW/Od6yloWGGbbY16aBtDlroCwAQEEdeqjQkpqunZgHBYDdByXtRwC?= =?Windows-1252?Q?Y9EVSFkJNvOE6bD/Qrx5zdS7TEQDlgupRNoXVs7wV5lIH41HbsLPXatD?= =?Windows-1252?Q?rnL7J6idGAVeIZ+tJYfAqPA0BUNlqenA5YW18uTO8OFDa2oR9Cdzn9A/?= =?Windows-1252?Q?3Hd8vEloTNxony1bUde3OPH6RcWLIMbMEdc/S2VwTu+FMTsw2x80Mmno?= =?Windows-1252?Q?3zqPLEkYBzHMyFtibrXvr8W/OKyGsrhm7BHIAoH6CsiKMxaaLEKdKxBA?= =?Windows-1252?Q?IFRhyMi3CsXj+JHMdrJGmht6cbIfju4JkkYHmmLlwf2d+xVBgF9zDeG3?= =?Windows-1252?Q?pVWY61nP6XgZX/XYTISe3HaKsUUIb+DDnCe0AUGnqwSdCaDcPYRqQFGE?= =?Windows-1252?Q?YMQDQB1loz9ZST6XLzqyEmz/FYHEmkMGzCjSoN6ChodZQQlmBd+fJLLx?= =?Windows-1252?Q?wkAkLo4tzGdko8PM/3LjGxE+z8AsSkmUlsuOFkwYuvR4GP0lSX6gbhbY?= =?Windows-1252?Q?WUxjGfFnP2gROVRanGAKo6m2xsmYEVHRNMkrmO/433R8Hjzr/KX8Bb1I?= =?Windows-1252?Q?+13ICP2o42JLnkKOs2a82emRISdR9D1qcBSIHmWSiBFk29RGxhLdto9n?= =?Windows-1252?Q?TSl9AW6KRNYj57JHXyrQQrKtJ6w7H9zS3/leXEYr1ZcWiP9eJEZqyM0F?= =?Windows-1252?Q?fTaDp6DXwImigAvovOakJ6td7p8m1FFKyWRduo128dQMp6u4qyNtg+1E?= =?Windows-1252?Q?pMdBjavlzdCx88xrweFt/56MzZF7xNccdyFWw030Q2uWfpvNp96zD5Zh?= =?Windows-1252?Q?Kj+glVlh/Jtif9kXUtg8QIvqfm2Yt1VZgMNk6G66EYtXa41LtdfkXvM3?= =?Windows-1252?Q?PjJtvIzQ9p83puDC6b3Dh8B2ThtIzRaHwamjCHpqT6faksC4w/NU/g?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR12MB3130828786A39BD24BA2D206CBF9ADM6PR12MB3130namp_" MIME-Version: 1.0 X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR12MB3130.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e2970a1-38ca-4913-f09f-08dbb9c46315 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2023 10:28:53.0066 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ZFutfy9QH44dMtNqreubmPp9DgwCIo0iiaene6IQPnKZCm+o2bULDTpf6fFE31AW9ZjZSfLCehHdtmf8k3HBaQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR12MB4305 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_DM6PR12MB3130828786A39BD24BA2D206CBF9ADM6PR12MB3130namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Can we add something about the fact that unspecified locality is nigh impos= sible when the code that is executed during the iteration is invisible to t= he compiler due to a procedure call? If I take the Peter example and put the loop body in a pure procedure, I ca= nnot 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 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. I don=92t expect us to solve this. I=92d just like to add the commonsense = thing that we all agree on, which is that unspecified locality is a terribl= e 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 , Malcol= m 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 is = that Do Concurrent means =93in any order=94 plus =93user hints that auto-pa= rallelization is desirable=94, which is to say, Do Concurrent may only be m= apped to =93!$omp parallel do" conditionally, after the compiler has proven= that the loop is legal to auto-parallelize. In this interpretation, Concurrent is still quite powerful, because it give= s the user a way to strongly encourage auto-parallelization, when compilers= may not otherwise do so aggressively because auto-parallelization all Do l= oops that are legal to do so with threads is likely to hurt performance, be= cause thread overhead is nontrivial. This should lead to high-quality impl= ementations of auto-parallelization (as I know Damian and friends want) and= sequential behavior only in pathological cases that most people aren=92t w= riting. It may interest some to know that yesterday during the OpenMP meeting, we d= ecided to settle the problem of =93!$omp loop=94 on Do Concurrent by adding= a restriction that users must specify the locality of variables that will = be written to in more than one iteration. This means that, in the context = of OpenMP, Peter=92s problematic example becomes erroneous unless the progr= ammer adds shared() appropriately, as you and Damian both suggest is the re= solution to this. Anyways, our implementation likely requires very little change to reflect t= his, since Do Concurrent can be implemented with OpenACC =93kernels=94, whi= ch causes the compiler to do auto-parallelization, based on what it can pro= ve is possible. I imagine that Intel will have to do more work, to disable= parallelism when it=92s 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 =93undefined=94 is =93having a specific = value=94. 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 ru= les when the inferred locality propagates, but the rules used for that infe= rence don=92t. Rules don=92t =93propagate=94. Rules are rules. I do not see anything odd about =93If I define the whole of array X in an i= teration, no other iteration can define the whole of array X=94 and =93If I= define an element of the array X in an iteration, no other iteration can d= efine that element of X=94. Perhaps it might help to think that DO CONCURRENT is not in fact a variatio= n of OpenMP !$OMP DO. That is not how it came about. DO CONCURRENT is two t= hings: 1. A reworking of FORALL to remove the plethora of array temps that FORA= LL often mandates. 2. A standardised form of the directive =93!DEC$IVDEP=94 (I probably hav= e that spelled wrong =96 the manuals are in the office.) This directive dec= lares that the loop iterations are independent, and that enables various us= eful loop optimisations, like software pipelining and so on. Now, in the =93simple=94 cases (and there are a lot of simple cases), it ca= n be easy to parallelise a DO CONCURRENT as originally designed (F2008), vi= z with everything =93unspecified locality=94, but although parallelisabilit= y was a strong consideration, it was not the driving force behind the origi= nal design. The drawbacks of unspecified locality re parallelisation are what lead to t= he introduction of specified locality in F2018. Seriously, users wanting good performance should not be using unspecified l= ocality, except perhaps in the simplest of loops. Actually, with my Softwar= e Engineering hat on, I=92d say users should not be using unspecified local= ity 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 varia= ble is, it should just execute the loop serially (in any order). That will = always give the correct answer, because loop iterations are independent (we= ll, the user claimed they were, anyway), and do not depend of what the loca= lity actually is. (If a =93parallelise DO CONCURRENT=94 option is active, i= t might be a good idea to produce a warning when this happens.) Anecdote: When I explained DO CONCURRENT to some OpenMP programmers, they w= ere aghast. =93Do not ever execute it in parallel!=94 was their response, w= ith the explanation =93If we want a loop executed in parallel we will use != $OMP PARALLEL DO, if the compiler might create threads on any other loop, t= hat would be excessive threads and would slow down the overall execution du= e to thread contention for resources.=94 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 <= sc22wg5@open-std.org>; 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 obv= iously propagates to subobjects, but (un)definedness obviously doesn=92t. This bothers me because we use (un)definedness to infer the locality of var= iables with unspecified locality. It is hard for me to understand how I ca= n apply the locality inference rules when the inferred locality propagates,= but the rules used for that inference don=92t. Jeff From: Clune, Thomas L. (GSFC-6101) > Date: Tuesday, 19. September 2023 at 16.17 To: General J3 interest list > Cc: Jeff Hammond >, WG5 <= sc22wg5@open-std.org>, 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=92t propagate to su= bobjects. E.g., if an array is allocatable, it=92s elements are not. = If an array is pointer, it=92s elements are not. And =93undefinedness=94 is very much a property of subobjects. Indeed, a = variable is only defined if all of its subobjects are defined. (I hope I h= ave 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 <= sc22wg5@open-std.org>, 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=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(1= 0) and A are not. Does the fact that A is undefined before and becomes und= efined during this loop imply anything about the undefined-ness of its elem= ents 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=92s not written there now, because, like, how could it possibl= y be anything else?=94 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 th= e undefined-ness does not. Why must I reason about the element-wise behavi= or 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 cont= ext, 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 nothin= g 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-const= ant 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 the= y are also variables, indeed, portions that can be defined and redefined se= parately, and being capable of being defined and redefined makes them varia= bles. We could add a NOTE to say that =93A 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.=94 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' > Subject: [ukfortran] [SC22WG5.6484] [J3] RE: [EXTERNAL] [BULK] are race con= ditions 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 i= s 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 a= n element of an array does not constitute definition of the variable, Correct (except in the trivial case of an array with a single element). Thi= s is all spelled out explicitly: defining every =93part=94 of a multi-part = variable defines the variable. I can see some potential wording improvements for the next revision, but no= thing that rises to the level of a defect. E.g. it may be better to mention that =93if a variable has SHARED locality,= all of its subobjects have SHARED locality=94. It=92s not written there no= w, 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= =93If a variable with SHARED locality is defined=85=94 instead of the curr= ent =93If it is defined=85=94. >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 comp= rehensibility (not for trail-following). So it=92s either deleting one of t= hem (ugh) or rewording one to break the circle without making it hard to un= derstand (it=92s not obvious exactly what to do here, which is why it is st= ill like this). If it were a glossary of terms, instead of a list of definitions, there wou= ld be no problem with circularity, right? Anyway, I agree it would be good to fix it as long as it doesn=92t 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 =93useful= =94 terms that do not lend themselves to trivial drop-in replacement, and I= think there are, we could consider adding a =93Glossary=94 (of =93useful t= erms=94, but probably better not to call them =93terms=94!). Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. From: Brad Richardson > Sent: Wednesday, September 13, 2023 3:49 AM To: General J3 interest list >; WG5 > Subject: [ukfortran] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race conditi= ons 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 executio= n of a program data entity data object (3.42), result of the evaluation of an expression, or the resul= t 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 s= yntax term. My reading of this is that we have a subtle contradiction between the synta= x and normative terms. My guess is that the syntax meaning (i.e. an array e= lement 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 iteration= s, but not valid to (un)define and reference the same element of an array i= n separate iterations. I think it would be worth "fixing" the terms and definitions to eliminate t= he 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: =93Variable=94 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 > on behalf of j3 > Reply-To: j3 > Date: Tuesday, September 12, 2023 at 12:19 PM To: j3 >, WG5 <= sc22wg5@open-std.org> 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 s= hall not be referenced, defined, or become undefined during any other itera= tion.", 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 wa= rranted, 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? =93If 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 refe= renced, defined, or become undefined during any other iteration.=94 If so, then I am struggling to apply this to arrays. When we say a variabl= e has shared locality, is the variable the array or the element? We can on= ly put array names in SHARED(), but applying the text regarding =93to becom= e defined=94 from the perspective of arrays appears to have interesting con= sequences. Thanks, Jeff --_000_DM6PR12MB3130828786A39BD24BA2D206CBF9ADM6PR12MB3130namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Can = we add something about the fact that unspecified locality is nigh impossibl= e when the code that is executed during the iteration is invisible to the c= ompiler 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 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.

 

I do= n=92t expect us to solve this.  I=92d just like to add the commonsense= thing that we all agree on, which is that unspecified locality is a terrib= le 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 non= e

  integer, int= ent(in) :: J, K, L

  real, intent= (in) :: A(:)

  real, intent= (out) :: B(:)

  real, intent= (inout) :: T(:)

  ! the implem= entation, found elsewhere, does this:=

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

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

end subroutine bar<= o:p>

end interface<= /o:p>

end module w

 

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

  use w

  implicit non= e

  integer, int= ent(in) :: N, K(N), L(N)

  real, intent= (in) :: A(N)

  real, intent= (out) :: B(N)

  real, intent= (inout) :: T(N)

  do concurren= t (integer :: J=3D1:N)

    = call bar(J,K(J),L(J),T,A,B)

  end do<= /o:p>

end subroutine foo<= o:p>

 

From: J3 <j3-bounces@m= ailman.j3-fortran.org> on behalf of Jeff Hammond via J3 <j3@mailman.j= 3-fortran.org>
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 Cohen <malcolm@nag-j.co.jp>
Subject: [J3] [SC22WG5.6491] RE: [EXTERNAL] [BULK] Subobject of a va= riable

External email: Use caution opening l= inks or attachments

 

Thanks, I have been= slowly coming around to a similar conclusion, which is that Do Concurrent = means =93in any order=94 plus =93user hints that auto-parallelization is de= sirable=94, which is to say, Do Concurrent may only be mapped to =93!$omp parallel do" conditionally, after the comp= iler has proven that the loop is legal to auto-parallelize.

 

In this interpretat= ion, 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-parallelization all Do loops that are legal to do so with threads is likely to hurt perfor= mance, because thread overhead is nontrivial.  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=92t writing.

 

It may interest som= e to know that yesterday during the OpenMP meeting, we decided to settle th= e problem of =93!$omp loop=94 on Do Concurrent by adding a restriction that= users must specify the locality of variables that will be written to in more than one iteration.  This means that,= in the context of OpenMP, Peter=92s problematic example becomes erroneous = unless the programmer adds shared() appropriately, as you and Damian both s= uggest is the resolution to this.

 

Anyways, our implem= entation likely requires very little change to reflect this, since Do Concu= rrent can be implemented with OpenACC =93kernels=94, which causes the compi= ler to do auto-parallelization, based on what it can prove is possible.  I imagine that Intel will have to do = more work, to disable parallelism when it=92s not legal.<= /p>

 

Jeff

 



On 20. Sep 2023, at= 11.56, Malcolm Cohen via J3 <j3@mailman.j3-fortran.org> wrote:<= /o:p>

 

External email: Use caution opening l= inks or attachments

 

Hi Jeff,

 <= /o:p>

The other side of a= variable being =93undefined=94 is =93having a specific value=94.

 <= /o:p>

No-one would expect= that having a specific value propagates to subobjects (the rank or type wo= uld be different).

 <= /o:p>

> It is hard for me t= o understand how I can apply the locality inference rules when the inferred locality propagates, but the rules used for that i= nference don=92t.

&nbs= p;

Rule= s don=92t =93propagate=94. Rules are rules.

&nbs= p;

I do= not see anything odd about =93If I define the whole of array X in an itera= tion, no other iteration can define the whole of array X=94 and =93If I def= ine an element of the array X in an iteration, no other iteration can define that element of X=94.

&nbs= p;

Perh= aps 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 CONCURRENT is two thing= s:

  1. A reworking of FORALL to remove the plethora of array temps that FORALL oft= en mandates.
  2. A standardised form of the directive =93!DEC$IVDEP=94 (I probably have that= spelled wrong =96 the manuals are in the office.) This directive declares = that the loop iterations are independent, and that enables various useful l= oop optimisations, like software pipelining and so on.

 <= /o:p>

Now, in the =93simp= le=94 cases (and there are a lot of simple cases), it can be easy to parall= elise a DO CONCURRENT as originally designed (F2008), viz with everything = =93unspecified locality=94, but although parallelisability was a strong consideration, it was not the driving force behind the origin= al design.

 <= /o:p>

The drawbacks of un= specified locality re parallelisation are what lead to the introduction of = specified locality in F2018.

 <= /o:p>

Seriously, users wa= nting good performance should not be using unspecified locality, except per= haps in the simplest of loops. Actually, with my Software Engineering hat o= n, I=92d 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.

 <= /o:p>

And for the compile= r, if it cannot work out what the locality of some variable is, it should j= ust execute the loop serially (in any order). That will always give the cor= rect 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 =93parallelise DO CONCURRENT=94= option is active, it might be a good idea to produce a warning when this h= appens.)

 <= /o:p>

Anecdote: When I ex= plained DO CONCURRENT to some OpenMP programmers, they were aghast. =93Do n= ot ever execute it in parallel!=94 was their response, with the explanation= =93If 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.=94

 <= /o:p>

Cheers,=

--

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

 <= /o:p>

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

 

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

&nbs= p;

This= bothers me because we use (un)definedness to infer the locality of variabl= es with unspecified locality.  It is hard for me to understand how I c= an apply the locality inference rules when the inferred locality propagates, but the rules used for that inference do= n=92t.

&nbs= p;

Jeff=

 <= /o:p>

From:&n= bsp;Clune= , Thomas L. (GSFC-6101) <thomas.l.clune@nasa.gov<= /span>>
Date: Tuesday, 19.= September 2023 at 16.17
To: General J3 int= erest list <j3@mailman.j3-fortran.org>
Cc: Jeff Hammond &= lt;jehammond@nvidia.com>, WG5 <sc22wg5@open-s= td.org>, Malcolm Cohen <malcolm@nag-j.co.jp>
Subject: Re: [EXTE= RNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a variable<= /p>

External email: Use caution opening l= inks or attachments

&nbs= p;

I do= not find this situation odd.    Lots of things don=92t prop= agate to subobjects.      E.g., if an array is all= ocatable, it=92s elements are not.  If an array is pointer, it=92s ele= ments are not.

&nbs= p;

And = =93undefinedness=94 is very much a property of subobjects.   Inde= ed, a variable is only defined if all of its subobjects are defined.  = (I hope I have that right.)

&nbs= p;

  • Tom=

&nbs= p;

F= rom: J3 <j3-bounces@mailman.j3-fortran.org> on behalf of j3 <j3@mailman.j3-fortran.org>
Reply-To: j3 <<= /span>j3@mailman.j3-fortran.org>
Date: Tuesday, Sep= tember 19, 2023 at 4:57 AM
To: j3 <= j3@mailman.j3-fortran.org>
Cc: Jeff Hammond &= lt;jehammond@nvidia.com>, WG5 <sc22wg5@open-s= td.org>, Malcolm Cohen <malcolm@nag-j.co.jp>
Subject: [EXTERNAL= ] [BULK] [J3] [SC22WG5.6486] Subobject of a variable

&nbs= p;

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




If a variable has unspecified = locality,

- if it is referenced in an it= eration it shall either be previously defined during that iteration, or sha= ll not be defined 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

&nbs= p;

do c= oncurrent (integer :: k=3D1:size(A))

&nbs= p; A(k) =3D k

&nbs= p; if (k.eq.1) A(10) =3D 0

end = do

&nbs= p;

As b= est I can tell, A(1:9) are defined after the loop terminates, while A(10) a= nd A are not.  Does the fact that A is undefined before and becomes un= defined 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?

&nbs= p;

Now = suppose I make A shared.  Malcolm said all the elements of A are share= d as well "It=92s not written there now, because, like, how could it p= ossibly be anything else?=94

&nbs= p;

real= , dimension(10) :: A

&nbs= p;

do c= oncurrent (integer :: k=3D1:size(A)) shared(A)

&nbs= p; A(k) =3D k

&nbs= p; if (k.eq.1) A(10) =3D 0

end = do

&nbs= p;

It i= s odd to me that the shared-ness of A propagates to its elements but the un= defined-ness does not.  Why must I reason about the element-wise behav= ior 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?

&nbs= p;

Jeff=

&nbs= p;




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

&nbs= p;

External email: Use caution opening l= inks or attachments

&nbs= p;

Hi B= rad,

&nbs= p;

Ther= e is no doubt that subobject includes array elements.

&nbs= p;

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

&nbs= p;

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

&nbs= p;  INTEGER,PARAMETER :: x(10) =3D [ 1,2,3,4,5,6,7,8,9,10 ]

&nbs= p;  READ *,I

&nbs= p;  PRINT *,x(I) 

&nbs= p;

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

&nbs= p;

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

&nbs= p;

We c= ould add a NOTE to say that =93A subobject of a variable is a variable, but= a subobject of a constant is not necessarily itself constant, e.g. if it h= as a non-constant subscript.=94 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.

&nbs= p;

Chee= rs,

--

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

&nbs= p;

&nbs= p;

Hi M= alcolm,

&nbs= p;

>= >variable/data entity/data object

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

&nbs= p;

>= Yes it does, see 3.138 subobject.

&nbs= p;

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

&nbs= p;

subo= bject of a constant

&nbs= p;

so t= he edit would be to change it to

&nbs= p;

subo= bject of a variable or constant

&nbs= p;

I do= n't think the circularity is causing too much confusion, so I don't see muc= h 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.

&nbs= p;

Rega= rds,

Brad=

&nbs= p;

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

Hi B= rad,

&nbs= p;

Ther= e is no contradiction, subtle or otherwise, here.

&nbs= p;

Loca= lity-specs are only for named variables. However, as noted, subobjects of v= ariables are also variables.

&nbs= p;

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

&nbs= p;

Corr= ect (except in the trivial case of an array with a single element). This is= all spelled out explicitly: defining every =93part=94 of a multi-part vari= able defines the variable.

&nbs= p;

I ca= n see some potential wording improvements for the next revision, but nothin= g that rises to the level of a defect.

&nbs= p;

E.g.= it may be better to mention that =93if a variable has SHARED locality, all= of its subobjects have SHARED locality=94. It=92s not written there now, b= ecause, like, how could it possibly be anything else? There is nothing else it could be.  But making it explicit woul= d lead naturally into writing =93If a variable with SHARED locality is defi= ned=85=94 instead of the current =93If it is defined=85=94.

&nbs= p;

>= variable/data entity/data object

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

&nbs= p;

Yes = it does, see 3.138 subobject.

&nbs= p;

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

&nbs= p;

If i= t were a glossary of terms, instead of a list of definitions, there would b= e no problem with circularity, right?

&nbs= p;

Anyw= ay, I agree it would be good to fix it as long as it doesn=92t make any ind= ividual term hard to understand.

&nbs= p;

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

&nbs= p;

Chee= rs,

--

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

&nbs= p;

F= rom: Brad Richardson <everythingfunctional@protonmail.com>&= nbsp;
Sent: Wednesday, S= eptember 13, 2023 3:49 AM
To: General J3 int= erest list <j3@mailman.j3-fortran= .org>; WG5 <sc22wg5@open-std.org<= span lang=3D"EN-US" style=3D"font-size:11.0pt">>
Subject: [ukfortra= n] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race conditions allowed in do = concurrent?

&nbs= p;

Hmm.= .. I decided to work through this a bit more thoroughly.<= /p>

&nbs= p;

From= the syntax definitions:

&nbs= p;

R902=

vari= able

is d= esignator

or f= unction-reference

&nbs= p;

R901=

desi= gnator

is o= bject-name

or a= rray-element

or a= rray-section

or c= oindexed-named-object

or c= omplex-part-designator

or s= tructure-component

or s= ubstring

&nbs= p;

&nbs= p;

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

&nbs= p;

From= the terms and definitions:

&nbs= p;

vari= able

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

&nbs= p;

data= entity

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

&nbs= p;

data= object

cons= tant, variable, or subobject of a constant

&nbs= p;

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

&nbs= p;

So n= ow the question is which "definition" does the DO CONCURRENT cons= traint refer to?

&nbs= p;

From= the syntax definitions:

&nbs= p;

R112= 9

conc= urrent-locality

is

[ lo= cality-spec ]...

&nbs= p;

R113= 0

loca= lity-spec

is L= OCAL ( variable-name-list )

or L= OCAL_INIT ( variable-name-list )

or R= EDUCE ( reduce-operation : variable-name-list )

or S= HARED ( variable-name-list )

or D= EFAULT ( NONE )

&nbs= p;

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

&nbs= p;

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

&nbs= p;

If a= variable has

&nbs= p;

whic= h is not hyperlinked and is not in a font indicating reference to the synta= x term.

&nbs= p;

My r= eading of this is that we have a subtle contradiction between the syntax an= d normative terms. My guess is that the syntax meaning (i.e. an array eleme= nt 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 refere= nce the same element of an array in separate iterations.<= /p>

&nbs= p;

I th= ink it would be worth "fixing" the terms and definitions to elimi= nate the circular definition and make it consistent with the syntax.=

&nbs= p;

Rega= rds,

Brad=

&nbs= p;

On T= ue, 2023-09-12 at 17:37 +0000, Clune, Thomas L. (GSFC-6101) wrote:

=93V= ariable=94 does not mean what we think it means:     &l= t;variable>   <<is>>  <designator> <= <or>> <function-reference>

&nbs= p;

And = <designator> includes <array-element>.

&nbs= p;

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

&nbs= p;

&nbs= p;

&nbs= p;

F= rom:J3 <j3-bounces@mailman.j3-fortran.org= > on behalf of j3 <j3@mailman.j3-f= ortran.org> Reply-To: j3 <<= /span>j3@mailman.j3-fortran.org<= span lang=3D"EN-US" style=3D"font-size:12.0pt">>
Date: Tuesday, Sep= tember 12, 2023 at 12:19 PM
To: j3 <= j3@mailman.j3-fortran.org>, WG5 <sc22wg5@open-std.org>
Cc: Brad Richardso= n <everythingfunctional= @protonmail.com&= gt;
Subject: [EXTERNAL= ] [BULK] [J3] [SC22WG5.6477] are race conditions allowed in do concurrent?<= /span>

&nbs= p;

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







Hi J= eff,

&nbs= p;

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

&nbs= p;

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, b= ecause it is then only partially defined. I.e. an array is only defined once each of its elements has been defined.

&nbs= p;

My o= pinion is that the above constraint simply does not adequately describe/is = still ambiguous about the case of arrays. I think an interp would be warran= ted, and we should say that an element of an array should have the same constraint as above if the variable is sh= ared.

&nbs= p;

Rega= rds,

Brad=

&nbs= p;

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

Is t= his a legal program in Fortran with defined behavior?  If it is illega= l or the behavior is undefined, where do we say that?

&nbs= p;

prog= ram main

&nbs= p; integer :: k

&nbs= p; real :: x

&nbs= p; x =3D 0.0

&nbs= p; do concurrent (k=3D1:2) shared(x)

&nbs= p;   x =3D real(k)

&nbs= p; end do

&nbs= p; print*,x

end = program main

&nbs= p;

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

&nbs= p;

=93I= f a variable has SHARED locality, appearances of the variable within the DO= CONCURRENT construct refer to the variable in the innermost executable con= struct 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.=94

&nbs= p;

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

&nbs= p;

Than= ks,


Jeff

 

--_000_DM6PR12MB3130828786A39BD24BA2D206CBF9ADM6PR12MB3130namp_--