From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Tue Sep 19 15:59:07 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 D53F8356948; Tue, 19 Sep 2023 15:59:06 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from NAM02-BN1-obe.outbound.protection.outlook.com (mail-bn1nam02on2046.outbound.protection.outlook.com [40.107.212.46]) by www.open-std.org (Postfix) with ESMTP id 10E763565B9 for ; Tue, 19 Sep 2023 15:59:05 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SHzunVwdgilHIdTEWGbUSIqnorjgptEFAyNsIbN2e3XddTVs9VpJBRkYctYEHqNppS1o2HWFWdXzbSutchhqaLqVXQEuwz+QdvOOZ56LK8SRgVQbjqbcEpg//GPu9lsqUQirbPGFfh6ya70H4o080KA0uQXS16XRtH8AVKxGsowaxRc2OtWeYzoRXSuqe4K6ZDr06/LAEFi6c8+C2R9QZgixzY74k5QpwKBUtOxiaBsIQ8fgUTOw6y2hdMkhOgIIgvSKl/5jQjQezYeYPsN2DIig0gUnjmeZAiXWfupF3EVypURIAefaPSiynkt0yET3SGp8q0hnDL/oaJ21VopxjA== 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=lj6Ss3jziyW/As8Kpdi0MN06zQwjhpMUQI3/tzyfSIA=; b=YZa/AQhJX/zYdhNCQR/4syCJy66yzrXjoXOdigSo2vpzlyJvtB78OOICI82f8U1VT25QDmWd33mEyU2pr+Pvk2qfHbyl/Bgmhyvvdg1WDUhBtBv8VNcapbd3hM/ScjZf4/2CBmGf1x7wuInjOoc40Ih0uSYlCfBQEqqZp5y7gsAT8W5gNppO0WAofpEOsqSfzSGyDXJ3LrALf8xf4HYp+gSe/NfPTISjuly6kV5uFF6S6eATZO+5w0o0tG+34g28HH3znyvuu7cYzkhRZm5MPn3Ich04qy3MIR03lOlol6ye5LZEoDdhOHtQtYnhYrg2ZKCtZCkQIvsfXDtb3//+dw== 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=lj6Ss3jziyW/As8Kpdi0MN06zQwjhpMUQI3/tzyfSIA=; b=UgzIdyUStI/89Hz4syunjN5bDc62RT8gkfjtJUQkXrz6vkSlgs+/SeLBI3r4U2ADJKDE+LDDKFFOjojtl0ikqEaTkbGdNDrQEZsXsuAzGB/cjzWuWB9tqDVrHc9soMyz3g70Usx9H5EZ8eVW0/hpYOEm1tsNdIaQ4Wi6jbSwngj6zzrGXvxDIcywGBKSi4jkJaZlk2ReSpC+EBmFWKZCs6831+5rC0ilCVG7asadTxOoIX1mwNzp/fPGBOnozvJB4K7MVNTuPkBkvAvAPIzDZwDkKGD0YPgvXI72msYEq9hiN5l8+Fs291dEAShq8kfRCaCuAwptzH6/iNlvFjzdIA== Received: from DM6PR12MB3130.namprd12.prod.outlook.com (2603:10b6:5:11b::16) by SJ0PR12MB7033.namprd12.prod.outlook.com (2603:10b6:a03:448::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6792.27; Tue, 19 Sep 2023 13:58:52 +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; Tue, 19 Sep 2023 13:58:52 +0000 From: Jeff Hammond To: "Clune, Thomas L. (GSFC-6101)" , General J3 interest list CC: WG5 , Malcolm Cohen Subject: Re: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a variable Thread-Topic: [EXTERNAL] [BULK] [J3] [SC22WG5.6486] Subobject of a variable Thread-Index: AQHZ6tdGOtVf0N67kkS/7lbB7qEFMLAiIWMAgAAKgBs= Date: Tue, 19 Sep 2023 13:58: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> In-Reply-To: <73963378-8AB0-447B-8BA0-EC90F07B0FEF@nasa.gov> 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_|SJ0PR12MB7033:EE_ x-ms-office365-filtering-correlation-id: 3d825e75-8c9e-4d0f-73fa-08dbb9188e8c x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pV0prMUyPSadKAhby7y+yJRe5rM9kMT1lQLUrRf4Bibt25ibwmMWQeq8iYitkW2lU5KR4HZ+L7dZlw8dwbY7QsVl/C8rwPuX/xCMOIsxm3kcQ9vftvTJ0P0uVfYOcW15/25pFJqzg4wmvbzuMhbSxF4ZoEXSInI1WEBW6LEKQocVDR5hdPNIZ4OQC1kTX4U7uLaL1kLXnYow3vHdXDPWvQfW8HlxjRKMd9Na2AdTsk+DkTyH0qHKLdlL6UrytGbedoMxaVHWhhQuZlOigThQBRS5OtArh3+TQjnPIvCyIXCMMFxhBnROZsxfxPVLieBfmWpcWrahYgyUyUppsNVNKslKHd2eVo/bP3ClBcKQ0O9qII730/3BNax3VKaLu9+pdjyuZ8wP02phcp7mc5Io3L5aaCop4M9jKO6aA59VN+Hpc4yh/kOgp85MZk88PcAcW+e5iYBJ6PLVss7fzQJjAXxoTf1ZrIVJNngGiBtKJU/UIfMLiIx4Ydn0L7zo7phI8XDzeZb/FvqZ7OvSlrNb1K/76aStkAfYrtaF47tqJdH9KX8vQxO3rhgS/KalT37agARS8vAKYgTMmesfN7YjzEBdqwgZLz9IUNZ/U5LNJPhJ6oa8hZloUXJZZlzy2g1K 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)(346002)(136003)(396003)(366004)(39860400002)(376002)(451199024)(186009)(1800799009)(122000001)(38100700002)(38070700005)(55016003)(33656002)(86362001)(478600001)(66446008)(66946007)(54906003)(64756008)(66556008)(66476007)(71200400001)(9686003)(2906002)(30864003)(110136005)(76116006)(53546011)(6506007)(7696005)(8676002)(8936002)(5660300002)(4326008)(52536014)(41300700001)(316002)(26005)(83380400001)(579004)(559001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?WimbZAbXuK9PeD/Asx+Mwiw35EajPpXJPdzjuVwjLT0RDyHWzukLxgsL?= =?Windows-1252?Q?yLdA5TvtLJD5IMsOzOsFXSqzHZRElxbJBudwHdWzxhs2964+iGkF5qlz?= =?Windows-1252?Q?qBDB9XuySDgX0dJjxkVudZgpKMtYOxIbiy0jF2Loxs/wHKN+UoQoAcx5?= =?Windows-1252?Q?pxQZddKTQvznSwafY7zeOrFYI6keYOnoY2Ny1GT+YfvHZtFWREnUY274?= =?Windows-1252?Q?kT8+SNZ9sL0dFHWHW5Zkoin98CC93bsSccamE+FuB0o+v1eTCQlQhgX2?= =?Windows-1252?Q?omuiFHOmkbKmChsVZX19rqi5IW+4VcETrqbPvdr+BNH2/yO09kr9L37Y?= =?Windows-1252?Q?6MHvVgSSNz7BLi8NSrWutUkenEBq4TImpJjqDSJwfTasfY7kzcyU2vVI?= =?Windows-1252?Q?F7ZduMmJRxoH9ptE1LeHWhYHzIdgh7Mwl1W5ECBlE7MziUww34Usygbq?= =?Windows-1252?Q?wdt4JUaf7V/tQol/TpFEyenPSVP2ej73PwJMx/3G+CQQEjnQnf7RagC4?= =?Windows-1252?Q?/xrbFdBdCk4vgApsdyhXe/Y84zFtpDIkuZA1mY2kMTnAyWppaAL4WKS+?= =?Windows-1252?Q?SsjbKhEDqqwkD8FGQFQyi4mP9UW0hitFpmnFe04ys77eyQZ/5Gahnh4b?= =?Windows-1252?Q?Rb5jI0rB7wTUzI12849y33C+OoUGjIZ1kraiF28gAOWVPR8dauFe+gK5?= =?Windows-1252?Q?oe5kl0jwGaNaGfHfxVqAaeM0QUHudvpoLFcKzred9QYHaaPvc2rlMFkI?= =?Windows-1252?Q?LT4ZYSvA+fRO9X3zADEfqOiaqmn8nZxa1ssK0mY6kBccRn10dXlK5f1L?= =?Windows-1252?Q?2mzka8H0KgvymipJqRFQfOOb2BDelxeKWTmT9P0BceTCP+1MgJmDCkEZ?= =?Windows-1252?Q?YJje4lXQHsv8JpLzQh5IWnaoa+mI2xKquWnOJDzApMq62b7LRb54mEnf?= =?Windows-1252?Q?TU3oGIJblvmqbUNr8ilXGu7balSGlmXsgqq7PWazm3U9Avlg0N+6xKDL?= =?Windows-1252?Q?Z121Md0thMpWdYnuk9pGqn6wxdYqLLOhiiQnMYZiCXYCJhJEqgdZ6Mrz?= =?Windows-1252?Q?4hO1pgcAyTbhwoKEbmpqE9szGWYPW9DnVmlKF9so/vY/0HQZUSaLP6Ug?= =?Windows-1252?Q?xWmBTwH5jAuy2SXC1RMcR54eSHkn4P+ZjPyhCnm25TcClotEQgxPqmDu?= =?Windows-1252?Q?WLpZiE4io9fThMaMNZ/YT/fRxzvOzrciP3M55JC7bDBeKHuljg/Ov9c+?= =?Windows-1252?Q?Bee+nSCRdG3JlZJwFzOJPmpKAEFrWEZ9g1Jil4U+9xJphQB2YFHKbTUz?= =?Windows-1252?Q?VdkSTYCwfbwVG4ly0cKEKF40T3TyeUvj0vd7UIrBD/+S5Xz5fg0vzFpz?= =?Windows-1252?Q?+bSXTYld1bdaerIH7pMs5Vn5a2bqqI146m4O7KwLvuuZT1/MlMeSEeww?= =?Windows-1252?Q?/ZRs5OdrXKF7rAastM2a5C9obI4AVbqfKwnyRBv8OHFpesOFd11kw5J8?= =?Windows-1252?Q?5YW4uoK/zDZxYMjJh4mHDMvOIL9fCCCVV9xazzy2EJuy30DYsFIm6dd7?= =?Windows-1252?Q?rdV5IQRTrNJVdoYam3JuH3GnS/49NyZ4H9B2ugyteACfUFRENYPFYFn8?= =?Windows-1252?Q?oY2kC491GYvNhdbe9QohmQMekCwFIQK6nI5b0iebrV1nCRoKFqOPdOMw?= =?Windows-1252?Q?Gon1GnCIZS/fqRAuoZ4z3kJG18Ty248FEtZm37pBxTQi8zNGbWDpBw?= =?Windows-1252?Q?=3D=3D?= Content-Type: multipart/alternative; boundary="_000_DM6PR12MB3130F647EF16E1D055CCD673CBFAADM6PR12MB3130namp_" 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: 3d825e75-8c9e-4d0f-73fa-08dbb9188e8c X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Sep 2023 13:58:52.4852 (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: dajBRJlvkUT6EDkWgZZA0GvsqZwKIT/RMHDlEkV+MuPpxREDGPGN7gB6jznAEwnIKwjO4CZ4qI+glc0xBF91cw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR12MB7033 Sender: owner-sc22wg5@open-std.org Precedence: bulk --_000_DM6PR12MB3130F647EF16E1D055CCD673CBFAADM6PR12MB3130namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 , Malcol= m 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 , Malcol= m 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_DM6PR12MB3130F647EF16E1D055CCD673CBFAADM6PR12MB3130namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Okay= , but we are saying that, in the context of do concurrent, locality obvious= ly propagates to subobjects, but (un)definedness obviously doesn=92t.<= /o: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.

 

Jeff=

 

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

External email: Use caution opening l= inks or attachments

 

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;

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

 

CAUTION: This email originated from outside of NA= SA.  Please take care when clicking links or opening attachments. = ; Use the "Report Message" button to report suspicious messages t= o 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

 

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 l= oop terminates, while A(10) and A are not.  Does the fact that A is un= defined before and becomes undefined during this loop imply anything about the undefined-ness of its elements during the lo= op or must one reason about them strictly independently, based on the eleme= nt-wise defined/undefined-ness?

 

Now suppose I make A shared.  Malcolm said al= l the elements of A are shared as well "It=92s not written there now, = because, like, how could it possibly 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 propagat= es 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 bec= omes 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 &l= t;j3@mailman.j3-fortran.org> wrote:

 

External email: Use caution opening l= inks or attachments<= /span>

 

Hi Brad,

 

There is no doubt that subobject includes array el= ements.

 

The point is that a subobject of a variable is its= elf a variable. So nothing more needs to be said on that front.<= /span>

 

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 co= nstant. It is a non-constant subobject of a constant!

 

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

 

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 w= e decide what to do with our overly-large set of terms.

 

Cheers,

--

..............Malcolm Cohen, NA= G Oxford/Tokyo.=

 

From: = Brad Richardson <everythingfunctional@protonmail.com> 
Sent: Thursday, Se= ptember 14, 2023 10:25 PM
To: General J3 int= erest list <j3@mailman.j3-fortran.org>; 'WG5' <sc22wg5@open= -std.org>
Subject: [ukfortra= n] [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 eleme= nts

 

> Yes it does, see 3.138 subobject.<= /span>

 

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 v= ia J3 wrote:

Hi Brad,

 

There is no contradiction, subtle or otherwise, he= re.

 

Locality-specs are only for named variables. Howev= er, as noted, subobjects of variables are also variables.=

 

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

 

Correct (except in the trivial case of an array wi= th a single element). This 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 nothing that rises to the level of a defect.

 

E.g. it may be better to mention that =93if a vari= able has SHARED locality, all of its subobjects have SHARED locality=94. It= =92s not written there now, because, like, how could it possibly be anything else? There is nothing else it could be. &nb= sp;But making it explicit would lead naturally into writing =93If a variabl= e with SHARED locality is defined=85=94 instead of the current =93If it is = defined=85=94.

 

>variable/data entity/data object

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

 

Yes it does, see 3.138 subobject.

 

The circularity is unfortunate, but they are all r= easonably worded for comprehensibility (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 o= bvious exactly what to do here, which is why it is still like this).

 

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

 

Anyway, I agree it would be good to fix it as long= as it doesn=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 terms=94, but probably= better not to call them =93terms=94!).

 

Cheers,

--

..............Malcolm Cohen, NA= G Oxford/Tokyo.=

 

From: = Brad Richardson <everythingfunctional@protonmail.com> 
Sent: Wednesday, S= eptember 13, 2023 3:49 AM
To: General J3 int= erest list <j3@mailman.j3-fortran.org>; WG5 <sc22wg5@open-st= d.org>
Subject: [ukfortra= n] [SC22WG5.6480] [EXTERNAL] [BULK] [J3] are race conditions allowed in do = concurrent?

 

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

 

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:<= /p>

 

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 ind= ividual 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 )<= /p>

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 te= xt, I.e.

 

If a variable has

 

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

 

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

 

I think it would be worth "fixing" the t= erms and definitions to eliminate the circular definition and make it consi= stent 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 mean= s:     <variable>   <<is>>&= nbsp; <designator> <<or>> <function-reference>=

 

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

 

But I for one would not mind an explanatory note t= hat clarifies the common use case of array elements in this context. <= o:p>

 

 

 

From:J3 <j3-bounces@mailman.j3-fortran.org> on behalf of j3 <j3@mailman.j3-fortran.org>
Reply-To: j3 <<= a href=3D"mailto:j3@mailman.j3-fortran.org">j= 3@mailman.j3-fortran.org>
Date: Tuesday, Sep= tember 12, 2023 at 12:19 PM
To: j3 <j3@mail= man.j3-fortran.org>, WG5 <sc22wg5@open-std.org> Cc: Brad Richardso= n <everythingfunctional@protonmail.com>
Subject: [EXTERNAL= ] [BULK] [J3] [SC22WG5.6477] are race conditions allowed in do concurrent?<= /span>

 

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

 

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

 

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

 

My opinion is that the above constraint simply doe= s not adequately describe/is still ambiguous about the case of arrays. I th= ink 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 vi= a J3 wrote:

Is this a legal program in Fortran with defined be= havior?  If it is illegal or the behavior is undefined, where do we sa= y 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 the DO CONCURRENT construct refer to the variable in= the innermost executable construct or scoping unit that includes the DO CONCURRENT construct. If it is defined or become= s undefined during any iteration, it shall not be referenced, defined, or b= ecome undefined during any other iteration.=94

 

If so, then I am struggling to apply this to array= s.  When we say a variable has shared locality, is the variable the ar= ray 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.<= span lang=3D"EN-US" style=3D"font-size:11.0pt">

 

Thanks,


Jeff

 

--_000_DM6PR12MB3130F647EF16E1D055CCD673CBFAADM6PR12MB3130namp_--