From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Fri May 16 05:13:46 2025 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 40F45356A3B; Fri, 16 May 2025 05:13:46 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 2802 seconds by postgrey-1.34 at www5.open-std.org; Fri, 16 May 2025 05:13:44 CEST Received: from www975.sakura.ne.jp (www975.sakura.ne.jp [219.94.128.215]) by www.open-std.org (Postfix) with ESMTP id A7C993568FB for ; Fri, 16 May 2025 05:13:43 +0200 (CEST) Received: from www975.sakura.ne.jp (localhost [127.0.0.1]) by www975.sakura.ne.jp (8.16.1/8.16.1) with ESMTP id 54G2QsVl010013 for ; Fri, 16 May 2025 11:26:55 +0900 (JST) (envelope-from malcolm@nag-j.co.jp) Received: from Maru10 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by www975.sakura.ne.jp (8.16.1/8.16.1) with ESMTPSA id 54G2QqJs010006 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 May 2025 11:26:54 +0900 (JST) (envelope-from malcolm@nag-j.co.jp) DKIM-Signature: a=rsa-sha256; bh=kE3pHFLvEJXlfK3wTzEFwAHqoa6gT+J4qmf6t5sFUVQ=; c=relaxed/relaxed; d=nag-j.co.jp; h=From:To:Subject:Date:Message-ID; s=rs20250417; t=1747362414; v=1; b=cKrvyI/0laDw9OVguhYxLbNksxawlBTM1DNGwnsikHRxGXpdXeCTM5xA3X8FwVAA RbisqO4AZ3ZeRgRabfnCWk5fE0XzFDdNAkVJMs7w6JNzn0+cJmRWuOE086VJjCPW dralr7/JZHHkegnXDQKp/dzB7CmeoFBO1EDX68PnUHAXIv3lmx5i7edIKmCuDPHj YywW8Z21svwVv4pmRHFV8SmLDLOz6q5zqkA+Jm6pEXpZLmQzFxYNgIzvJDE/TFpJ N6tdNqpIgssjHri40VJFLgudNVIVwS87fTvtj6xLewQfCzTTThAg1GyxBZSdEBj2 J6TPeYi3O5JohDb2uUvk6g== From: "Malcolm Cohen" To: "'sc22wg5'" Subject: WG5 letter ballot 1 on Fortran 2023 interpretations Date: Fri, 16 May 2025 11:26:52 +0900 Message-ID: <002201dbc609$fd48e5e0$f7dab1a0$@nag-j.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0023_01DBC655.6D356FE0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdvGCTwV5jwFqK68Rii+wfTla8M2dw== Content-Language: ja X-Virus-Status: clean X-Anti-Virus-Server: fsav404.rs.sakura.ne.jp Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_0023_01DBC655.6D356FE0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0024_01DBC655.6D356FE0" ------=_NextPart_001_0024_01DBC655.6D356FE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, Attached is the first WG5 letter ballot on Fortran 2023 interpretations. I have made it a J3 paper for now, I expect it will be promoted to be a WG5 paper in due course. This is a 30-day letter ballot starting immediately. For convenience, I reproduce the "action" part of the ballot below. The following Fortran 2023 interpretations are being balloted: Yes No Number Title --- --- F23/003 Conflicting rules for COMMON block names --- --- F23/004 OUT_OF_RANGE and ROUND argument --- --- F23/005 Defined assignment/operators and dynamic type --- --- F23/006 Underflow in IEEE_SCALB --- --- F23/008 Real argument I in IEEE_SCALB --- --- F23/009 Coarray subobject of component --- --- F23/010 MOVE_ALLOC with coarray arguments --- --- F23/011 NULL and procedure pointers --- --- F23/012 Coarray correspondence in DEALLOCATE --- --- F23/013 BOZ literals in interoperable enumerators --- --- F23/015 Coindexed objects in structure constructors --- --- F23/016 Segments associated with allocation --- --- F23/017 CFI_establish nonalloc nonpointer null base address --- --- F23/018 Correspondence of unallocated coarrays Please mark the above -Y- in the Yes column for "yes", -C- in the Yes column for "yes with comment", or -N- in the No column for a "no" answer {be sure to include your reasons with "no"} and send ONLY the vote section to sc22wg5@open-std.org by 23:59 UTC on June 15, 2025, in order to be counted. Thanks, Malcolm on behalf of Steve Lionel NB: Be careful not to attach the whole ballot to your email, we just need the votes as above with any comments/reasons. Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. ------=_NextPart_001_0024_01DBC655.6D356FE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

Attached is the first = WG5 letter ballot on Fortran 2023 interpretations. I have made it a J3 = paper for now, I expect it will be promoted to be a WG5 paper in due = course. This is a 30-day letter ballot starting = immediately.

 

For convenience, I = reproduce the “action” part of the ballot = below.

 

The following Fortran = 2023 interpretations are being balloted:

 

Yes  = No   Number    Title

 

---  ---  = F23/003  Conflicting rules for COMMON block = names

---  ---  F23/004  = OUT_OF_RANGE and ROUND argument

---  ---  = F23/005  Defined assignment/operators and dynamic = type

---  ---  F23/006  Underflow = in IEEE_SCALB

---  ---  F23/008  Real = argument I in IEEE_SCALB

---  ---  F23/009  Coarray = subobject of component

---  ---  F23/010  MOVE_ALLOC = with coarray arguments

---  ---  F23/011  NULL and = procedure pointers

---  ---  F23/012  Coarray = correspondence in DEALLOCATE

---  ---  = F23/013  BOZ literals in interoperable = enumerators

---  ---  F23/015  Coindexed = objects in structure constructors

---  ---  = F23/016  Segments associated with = allocation

---  ---  F23/017  = CFI_establish nonalloc nonpointer null base = address

---  ---  F23/018  = Correspondence of unallocated coarrays

 

Please mark the above = -Y- in the Yes column for "yes", -C- in the = Yes

column for "yes with comment", or = -N- in the No column for a "no"

answer {be sure to = include your reasons with "no"} and send ONLY = the

vote section to

 

        = sc22wg5@open-std.org

 

by 23:59 UTC on June = 15, 2025, in order to be counted.

 

Thanks,

Malcolm on behalf of = Steve Lionel

 

NB: Be careful not to = attach the whole ballot to your email, we just need the votes as above = with any comments/reasons.

 

Cheers,

-- =

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

 

------=_NextPart_001_0024_01DBC655.6D356FE0-- ------=_NextPart_000_0023_01DBC655.6D356FE0 Content-Type: text/plain; name="25-134.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="25-134.txt" To: J3 J3/25-134=0A= From: Malcolm Cohen=0A= Subject: WG5 letter ballot 1 on Fortran 2023 interpretations=0A= Date: 2025-May-16=0A= =0A= This J3 paper will be promoted to be a WG5 paper in due course.=0A= =0A= This is the first set of draft interpretations for Fortran 2023.=0A= They have all been approved in a J3 letter ballot.=0A= =0A= The rules we operate on say:=0A= =0A= 4. The chair of J3/interp gathers all interp answers that are marked=0A= "passed by J3 letter ballot" and forwards them to the WG5 convenor.=0A= The WG5 convenor holds a ballot of individual members; a no vote=0A= must be accompanied by an explanation of the changes necessary to=0A= change the member's vote to yes. The answers that pass this ballot=0A= become "WG5 approved".=0A= =0A= J3/interp reserves the right to recall an interp answer for more=0A= study even if the answer passes.=0A= =0A= 5. "WG5 approved" answers are processed into a corrigendum document by=0A= taking the edits from the interp answers and putting them in the=0A= format required by ISO. A WG5 vote is made on forwarding the=0A= corrigendum to SC22.=0A= =0A= The following Fortran 2023 interpretations are being balloted:=0A= =0A= Yes No Number Title=0A= =0A= --- --- F23/003 Conflicting rules for COMMON block names=0A= --- --- F23/004 OUT_OF_RANGE and ROUND argument=0A= --- --- F23/005 Defined assignment/operators and dynamic type=0A= --- --- F23/006 Underflow in IEEE_SCALB=0A= --- --- F23/008 Real argument I in IEEE_SCALB=0A= --- --- F23/009 Coarray subobject of component=0A= --- --- F23/010 MOVE_ALLOC with coarray arguments=0A= --- --- F23/011 NULL and procedure pointers=0A= --- --- F23/012 Coarray correspondence in DEALLOCATE=0A= --- --- F23/013 BOZ literals in interoperable enumerators=0A= --- --- F23/015 Coindexed objects in structure constructors=0A= --- --- F23/016 Segments associated with allocation=0A= --- --- F23/017 CFI_establish nonalloc nonpointer null base address=0A= --- --- F23/018 Correspondence of unallocated coarrays=0A= =0A= The text of these interpretations appears below.=0A= Each interpretation starts with a row of "-"s.=0A= =0A= Please mark the above -Y- in the Yes column for "yes", -C- in the Yes=0A= column for "yes with comment", or -N- in the No column for a "no"=0A= answer {be sure to include your reasons with "no"} and send ONLY the=0A= vote section to=0A= =0A= sc22wg5@open-std.org=0A= =0A= by 23:59 UTC on June 15, 2025, in order to be counted.=0A= =0A= Thanks,=0A= Malcolm on behalf of Steve Lionel=0A= =0A= =0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/003=0A= TITLE: Conflicting rules for COMMON block names=0A= KEYWORDS: COMMON Block, Named Constant, USE association renaming=0A= DEFECT TYPE: Clarification/Erratum=0A= STATUS: Passed by J3 letter ballot=0A= REFERENCES: N2209=0A= =0A= QUESTION:=0A= =0A= A survey of five compilers finds that three disallow a named constant=0A= from having the same name as a COMMON block in a give scope, while two=0A= compilers permit named constants sharing the same name as a COMMON=0A= block accessible in the same scope.=0A= =0A= 19.3.1 Classes of local identifiers, paragraph 1 establishes identifiers=0A= of names constants to be class (1) identifiers. Paragraph 2 states:=0A= =0A= "Within a scope, a local identifier of an entity of class (1) or=0A= class(4) shall not be the same as a global identifier used in that=0A= scope unless the global identifier=0A= o ...=0A= o is a common block name=0A= o ..."=0A= =0A= However, 19.3.2 Local identifiers that are the same as common block=0A= names states:=0A= =0A= "A name that identifies a common block in a scoping unit shall not be=0A= used to identify a constant or an intrinsic procedure in that=0A= scoping unit. ..."=0A= =0A= which disallows a named constant from having the same name as an=0A= accessible common block.=0A= =0A= 14.2.2 The USE statement and use association contains Note 4 which=0A= states=0A= =0A= "The constraints in 8.10.1, 8.10.2, and 8.9 prohibit the local-name=0A= from appearing in a COMMON statement, and equivalence-object in an=0A= EQUIVALENCE statement, or a namelist-group-name in a NAMELIST state-=0A= ment, respectively. There is no prohibition against the local-name=0A= appearing as a common-block-name or a namelist-group-object."=0A= =0A= The last sentence of this note contradicts the restrictions in 19.3.2.=0A= =0A= Q. Is the intent to disallow a local identifier that identifies a=0A= named constant from being the same as an accessible common block?=0A= =0A= ANSWER:=0A= =0A= Yes, the local identifier of a named constant cannot be the same as=0A= that of an accessible common block. This issue goes back to FORTRAN 77=0A= when the PARAMETER statement was introduced. When Fortran 90=0A= introduced MODULEs and USE association, the restriction on common=0A= block names was overlooked when the note was written.=0A= =0A= Clarifying edits are provided.=0A= =0A= EDITS to N2209:=0A= =0A= [299] 14.2.2 The USE statement and use association, NOTE 4, sentence 2=0A= delete=0A= "a common-block-name or"=0A= add at the end of the note=0A= "Restrictions on local-name being the same as a common-block-name=0A= are detailed in 19.3.2."=0A= =0A= [528:15] 19.3.1 Classes of local identifiers, p2,=0A= after "is a common block name (19.3.2)"=0A= insert "and the local identifier is not that of a named=0A= constant or intrinsic procedure,"=0A= =0A= SUBMITTED BY: Jon Steidel=0A= =0A= HISTORY: 23-119 m229 Submitted=0A= 23-119r1 m229 Revised edit location/description, approved uc=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/004=0A= TITLE: OUT_OF_RANGE and ROUND argument=0A= KEYWORDS: OUT_OF_RANGE=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= In the description of the intrinsic function=0A= =0A= OUT_OF_RANGE (X, MOLD [, ROUND])=0A= =0A= it states "ROUND shall be present only if X is of type real and=0A= MOLD is of type integer."=0A= =0A= Consider=0A= =0A= Program test=0A= Call s(1.5,2.5)=0A= Contains=0A= Subroutine s(x,y,r)=0A= Logical,Optional :: r=0A= Print *,out_of_range(x,y,r) ! Valid?=0A= End Subroutine=0A= End Program=0A= =0A= As R is an optional dummy argument, it is present only if the actual=0A= argument is present. In this example, R is not present, and so the=0A= requirement in 16.9.157 is satisfied.=0A= =0A= Was it intended that this program be valid?=0A= (Of the two compilers that implement OUT_OF_RANGE that I tested,=0A= both of them rejected the program.)=0A= =0A= ANSWER:=0A= =0A= No, it was not intended that the example be valid; the requirement=0A= should have stated that the argument shall not appear.=0A= =0A= An edit is provided.=0A= =0A= EDIT to N2209.=0A= =0A= [422] 16.9.157 OUT_OF_RANGE, Arguments paragraph, ROUND argument,=0A= change "shall be present only" to "shall appear only".=0A= =0A= SUBMITTED BY: Malcolm Cohen=0A= =0A= HISTORY: 23-114 m229 Submitted, approved uc=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/005=0A= TITLE: Defined assignment/operators and dynamic type=0A= KEYWORDS: Defined assignment, defined operations, dynamic type=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= 10.2.1.4 Defined assignment statement states that a subroutine=0A= "defines the defined assignment x1 =3D x2 if=0A= (1) the subroutine is specified with a SUBROUTINE (15.6.2.3) ...=0A= statement that specifies two dummy arguments, d1 and d2,=0A= [and]=0A= (3) the types of d1 and d2 are compatible with the dynamic types=0A= of x1 and x2, respectively,"=0A= =0A= Furthermore, 10.2.1.2 Intrinsic assignment statement states=0A= "An intrinsic assignment statement is an assignment statement=0A= that is not a defined assignment statement (10.2.1.4)."=0A= =0A= This means that=0A= (i) in the situation where there is no intrinsic assignment, whether=0A= there is a defined assignment (and thus the program is valid)=0A= depends on the dynamic types, not the declared types;=0A= (ii) in the situation where there may be an intrinsic assignment for=0A= a derived type, whether this is overridden by defined assignment=0A= again depends on the dynamic types.=0A= =0A= Similar wording appears in in 10.1.6 Defined operations, specifically=0A= in 10.1.6.1 Definitions, paragraph 2, item (3), and paragraph 5 item=0A= (3). Similar conclusions follow.=0A= =0A= These consequences are contrary to the principle that generic=0A= resolution is determined statically, that is, at compile time.=0A= Generic resolution is indeed done statically for generic names and=0A= generic type-bound procedures. It would be very surprising for it=0A= not to be done statically for generic assignment and operators.=0A= =0A= For example, consider=0A= =0A= Module c23_005=0A= Type t=0A= Integer c=0A= End Type=0A= Type,Extends(t) :: t2=0A= Integer d=0A= End Type=0A= Generic :: Assignment(=3D) =3D> assign_t2_int=0A= Contains=0A= Subroutine assign_t2_int(a,b)=0A= Class(t2),Intent(InOut) :: a=0A= Integer,Intent(In) :: b=0A= a%c =3D b=0A= a%d =3D -b=0A= End Subroutine=0A= End Module=0A= Program test=0A= Use c23_005=0A= Class(t),Allocatable :: x=0A= Allocate(x,Source=3Dt2(1,2))=0A= x =3D 12345 ! (1)=0A= Print *,x%c=0A= End Program=0A= =0A= =0A= There is no intrinsic assignment at (1), so the program would be=0A= invalid unless generic resolution is done on the dynamic type.=0A= =0A= Consider=0A= =0A= Module c23_005a=0A= Type t=0A= Integer c=0A= End Type=0A= Type,Extends(t) :: t2=0A= Integer d=0A= End Type=0A= Generic :: Assignment(=3D) =3D> assign_t2_t=0A= Contains=0A= Subroutine assign_t2_t(a,b)=0A= Class(t2),Intent(InOut) :: a=0A= Type(t),Intent(In) :: b=0A= a%c =3D b%c**2=0A= a%d =3D -b%c**2=0A= End Subroutine=0A= Subroutine sho(w)=0A= Class(t),Intent(In) :: w=0A= Select Type (w)=0A= Type Is (t)=0A= Print *,'t:',w=0A= Type Is (t2)=0A= Print *,'t2:',w=0A= End Select=0A= End Subroutine=0A= End Module=0A= Program test=0A= Use c23_005a=0A= Class(t),Allocatable :: x=0A= Allocate(x,Source=3Dt2(1,2))=0A= x =3D t(9) ! (2)=0A= Call sho(x)=0A= End Program=0A= =0A= Intrinsic assignment would be available for the assignment at (2),=0A= but if generic resolution were done on the dynamic type, the defined=0A= assignment would be executed, not the intrinsic assignment. That=0A= affects the result - does the program print "t: 9" or "t2: 81 -81".=0A= =0A= It does not have to be the left-hand-side that is polymorphic:=0A= consider=0A= =0A= Module c23_005b=0A= Type t=0A= Integer c=0A= End Type=0A= Type,Extends(t) :: t2=0A= Integer d=0A= End Type=0A= Generic :: Assignment(=3D) =3D> assign_t_t2=0A= Contains=0A= Subroutine assign_t_t2(a,b)=0A= Type(t),Intent(Out) :: a=0A= Class(t2),Intent(In) :: b=0A= a%c =3D b%c**2 - b%d**2=0A= End Subroutine=0A= End Module=0A= Program test=0A= Use c23_005b=0A= Class(t),Allocatable :: x=0A= Type(t) y=0A= Allocate(x,Source=3Dt2(1,2))=0A= y =3D x ! (3)=0A= Print *,y=0A= End Program=0A= =0A= Here the question is whether the program prints "1" for generic=0A= resolution of the statement at (3) done at compile time (and thus the=0A= intrinsic assignment), or "-3" for generic resolution done at=0A= execution time (and thus the defined assignment).=0A= =0A= For defined operations, consider=0A= =0A= Module c23_005c=0A= Type t=0A= Integer c=0A= End Type=0A= Type,Extends(t) :: t2=0A= Integer d=0A= End Type=0A= Generic :: Operator(+) =3D> t2_plus_int=0A= Contains=0A= Type(t2) Function t2_plus_int(a,b) Result(r)=0A= Class(t2),Intent(In) :: a=0A= Integer,Intent(In) :: b=0A= r%c =3D a%c + b=0A= r%d =3D a%d - b=0A= End Function=0A= End Module=0A= Program test=0A= Use c23_005c=0A= Class(t),Allocatable :: x=0A= Allocate(x,Source=3Dt2(1,2))=0A= Print *,x+10 ! (4)=0A= End Program=0A= =0A= This is valid only if the dynamic type is used to resolve the generic=0A= operation at (4) in favour of the defined operation, even though the=0A= compiler has no idea what the declared type might be at runtime.=0A= =0A= One final consideration is that type compatibility is between=0A= entities, not between types. Therefore, the quoted words=0A= "the types of d1 and d2 are compatible with the dynamic types=0A= of x1 and x2"=0A= have no meaning, and thus by subclause 4.2 Conformance, paragraph 1,=0A= "A program (5.2.2) is a standard-conforming program ... if the=0A= program has an interpretation according to this document"=0A= all programs which attempt to use defined assignment or operators are=0A= non-conforming.=0A= =0A= So the question is, should generic resolution of defined assignment=0A= and defined operators follow the dynamic type, as suggested by the=0A= current wording?=0A= =0A= DISCUSSION:=0A= =0A= These words come from paper 02-129r2 at meeting 160, which claimed to=0A= be making no technical change. The editor wrote in his report=0A= "These seem more than editorial. Looks like a couple of dynamic=0A= and declared types got switched around for a start. And same=0A= type got changed to compatable type. I'll just assume it is all=0A= correct."=0A= =0A= Unfortunately, no-one followed up on the report.=0A= =0A= No compilers have been reported as following the implications of the=0A= current wording - they all use the declared types for generic=0A= resolution, just like normal type compatibility.=0A= =0A= ANSWER:=0A= =0A= No, generic resolution of defined assignment and defined operations=0A= should follow the rules for type compatibility, which uses the=0A= declared type not the dynamic type.=0A= =0A= It is noted that the rules for argument association already include=0A= the correct wording; 15.5.2.5 Ordinary dummy variables, p2, states=0A= "The dummy argument shall be type compatible with the actual=0A= argument."=0A= =0A= Edits are provided to correct this misstatement.=0A= =0A= EDITS to N2209.=0A= =0A= [161:6] 10.1.6 Defined operations, 10.1.6.1 Definitions, p2, (3),=0A= Change=0A= "the type of d2 is compatible with the dynamic type of x2,"=0A= to=0A= "d2 is type-compatible with x2,"=0A= =0A= [161:23] Same subclause, p5, (3),=0A= Change "the types of d1 and d2 are compatible with the dynamic=0A= types of x1 and x2, respectively,"=0A= to=0A= "d1 and d2 are type-compatible with x1 and x2, respectively,"=0A= =0A= [172:13] 10.2.1.4 Defined assignment statement, p2, (3),=0A= Change "the types of d1 and d2 are compatible with the dynamic=0A= types of x1 and x2, respectively,"=0A= to=0A= "d1 and d2 are type-compatible with x1 and x2, respectively,"=0A= {Note the lines in NOTE 8 at the top of the page do not count towards=0A= the line number in the interpretation document.}=0A= =0A= SUBMITTED BY: Malcolm Cohen & Jon Steidel=0A= =0A= HISTORY: 23-118 m229 Submitted, approved uc=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/006=0A= TITLE: Underflow in IEEE_SCALB=0A= KEYWORDS: Underflow, IEEE_SCALB=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= If X * 2**I is too small to be represented with full accuracy, was it=0A= intended that IEEE_SCALB(X,I) should return the representable number=0A= having a magnitude nearest to ABS(2**I) and the same sign as X? For=0A= example, if X is IEEE binary32 with the value 2E-38, was it=0A= intended that IEEE_SCALB(X,-1) should return the value 0.5?=0A= =0A= =0A= ANSWER:=0A= No, it was intended that it should return the representable number=0A= having a magnitude nearest to ABS(X*2**I) and the same sign as X.=0A= An edit is supplied.=0A= =0A= This error dates back to Fortran 2003. Therefore this is an=0A= incompatibility with Fortran 2003, 2008, and 2018. Edits to the=0A= compatibility subclause are provided.=0A= =0A= EDITS to N2218:=0A= =0A= [xiii] Introduction, Intrinsic modules bullet, append sentence=0A= "The result of the function IEEE_SCALB from the intrinsic module=0A= IEEE_ARITHMETIC has been corrected to conform to \theIEEEstd."=0A= =0A= [33:13+] 4.3.3 Fortran 2018 compatibility, last paragraph, new bullet=0A= "- The result of a reference to the function IEEE_SCALB from the=0A= intrinsic module IEEE_ARITHMETIC has been corrected to return=0A= the representable number having a magnitude nearest to=0A= ABS(X*2**I) with the same sign as X, if X*2**I is too small to=0A= be represented with full accuracy."=0A= =0A= [34:17+] 4.3.4 Fortran 2008 compatibility, last paragraph, new bullet=0A= with text identical to preceding edit.=0A= =0A= [35:13+] 4.3.5 Fortran 2003 compatibility, last paragraph, new bullet=0A= with text identical to the edit for [33:13+].=0A= =0A= [487:15] 17.11.37 IEEE_SCALB, Result Value paragraph, Case (iii),=0A= change "|2^I|" to "|X \times 2^I|".=0A= =0A= SUBMITTED BY: John Reid=0A= =0A= HISTORY: 23-156 m230 Submitted=0A= 23-156r1 m230 Revised edits, approved uc=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/008=0A= TITLE: Real argument I in IEEE_SCALB=0A= KEYWORDS: Real, IEEE_SCALB=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= The first sentence of 17.1 Overview of IEEE arithmetic support, states=0A= "The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and=0A= IEEE_FEATURES provide support for the facilities defined by=0A= ISO/IEC 60559:2020."=0A= However, nothing claims to support the IEEE function scaleB. This is=0A= very like IEEE_SCALB (X,I) except that the IEEE standard requires=0A= that the second argument to scaleB be the same type as logB, and that=0A= is Real type whereas IEEE_SCALB only accepts Integer type.=0A= =0A= Was it intended to support the IEEE scaleB operation?=0A= If so, is that intended to be provided by IEEE_SCALB?=0A= =0A= ANSWER:=0A= =0A= Yes, the IEEE scaleB operation should have been supported.=0A= =0A= Yes, IEEE_SCALB should provide the scaleB operation.=0A= =0A= EDITS to N2218:=0A= =0A= [xiv] Introduction, bullet "Changes to the intrinsic module=0A= IEEE_ARITHMETIC for conformance with ISO/IEC 60559:2020",=0A= append sentence=0A= "The function IEEE_SCALB from the intrinsic module=0A= IEEE_ARITHMETIC now performs the scaleB operation."=0A= =0A= [470:6-7] 17.9 IEEE arithmetic, p1, bullet list, last item,=0A= After "logB," insert "scaleB,",=0A= After "IEEE_LOGB," insert "IEEE_SCALB".=0A= =0A= [487:6] 17.11.37 IEEE_SCALB, Arguments, I, change "integer" to=0A= "integer or of type real with the same kind type parameter as X"=0A= so that the line reads=0A= "I shall be of type integer or of type real with the same kind=0A= type parameter as X.".=0A= =0A= [487:9+] Same subclause, Result Value, before "Case (i)", insert=0A= "The value of the result shall conform to the scaleB operation=0A= of \theIEEEstd.".=0A= =0A= SUBMITTED BY: John Reid=0A= =0A= HISTORY: 23-157 m230 Submitted=0A= 23-157r1 m230 Revised=0A= 23-157r2 m230 Revised, passed by J3 meeting=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/009=0A= TITLE: Coarray subobject of component=0A= KEYWORDS: coarray, allocatable, array, component=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= The Introduction of Fortran 2023 says=0A= "A data object with a coarray component can be an array or=0A= allocatable."=0A= =0A= This appears to be true for named variables, but there is a constraint=0A= that makes it impossible for an array component or an allocatable=0A= component:=0A= "C753 A data component whose type has a coarray potential subobject=0A= component shall be a nonpointer nonallocatable scalar and=0A= shall not be a coarray."=0A= =0A= That means that given the type=0A= =0A= Type real_coarray=0A= Real,Allocatable :: c[:]=0A= End Type=0A= =0A= the statements=0A= =0A= Type(real_coarray) x(100)=0A= Type(real_coarray),Allocatable :: y=0A= =0A= are acceptable as type declaration statements, but unacceptable as=0A= component definition statements.=0A= =0A= Is this irregularity deliberate?=0A= =0A= ANSWER:=0A= =0A= No, this constraint was accidentally overlooked when extending types=0A= with coarray components to be subobjects of arrays and allocatables.=0A= =0A= An edit is provided to correct this mistake.=0A= =0A= EDIT to N2218 (Fortran 2023 FDIS):=0A= =0A= [79:constraint C753] In subclause=0A= Delete this constraint, which begins=0A= "C753 A data component whose type has a coarray"=0A= =0A= [80:After NOTE 1] Insert new NOTE=0A= "NOTE 1.5=0A= A data component whose type has a coarray potential subobject=0A= component cannot be a coarray or a pointer, see constraint C825."=0A= {C825 says "An entity whose type has a coarray potential subobject..."=0A= and components are certainly entities. We specifically wrote "entity"=0A= instead of "named variable" to cover the component case.=0A= I prefer to say it once and refer to it.}=0A= =0A= SUBMITTED BY: John Reid & Reinhold Bader=0A= =0A= HISTORY: 23-210 m231 Submitted=0A= 23-210r1 m231 Revised=0A= 23-210r2 m231 Passed as amended by J3 meeting 231.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/010=0A= TITLE: MOVE_ALLOC with coarray arguments=0A= KEYWORDS: MOVE_ALLOC, coarray=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= If the FROM and TO arguments to MOVE_ALLOC are coarrays, are=0A= corresponding invocations of MOVE_ALLOC required to have their FROM=0A= (and TO) arguments be corresponding coarrays?=0A= =0A= For example, this program ends up with A and B not having the same=0A= allocation status on all images, which surely cannot be right.=0A= =0A= program trouble=0A= real, allocatable :: a[:], b[:]=0A= allocate(a[*],b[*])=0A= if (this_image()>1) then=0A= call sub(a,b)=0A= ! Now, A is deallocated and B is allocated=0A= else=0A= call sub(b,a)=0A= ! Now, B is deallocated and A is allocated=0A= end if=0A= contains=0A= subroutine sub(s,t)=0A= real, allocatable :: s[:], t[:]=0A= call move_alloc(s,t)=0A= end subroutine=0A= end program=0A= =0A= ANSWER:=0A= =0A= Yes, those arguments are required to be corresponding coarrays.=0A= An edit is supplied to correct this error.=0A= =0A= EDIT to N2218 (Fortran 2023 FDIS):=0A= =0A= [423] In 16.9.147 MOVE_ALLOC, Arguments paragraph,=0A= At the end of the FROM argument description append=0A= "If it is a coarray, it shall correspond to the FROM arguments=0A= in all corresponding invocations of MOVE_ALLOC."=0A= At the end of the TO argument description append=0A= "If it is a coarray, it shall correspond to the TO arguments=0A= in all corresponding invocations of MOVE_ALLOC."=0A= =0A= SUBMITTED BY: John Reid & Reinhold Bader=0A= =0A= HISTORY: 23-170 m230 Submitted=0A= 23-220 m231 Revised=0A= 23-220r1 m231 Revised, passed by J3 meeting 231.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/011=0A= TITLE: NULL and procedure pointers=0A= KEYWORDS: NULL, procedure pointer=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= Consider the procedure declaration statement=0A= =0A= PROCEDURE(), POINTER :: PROCPTR =3D> NULL()=0A= =0A= The statement appears to violate the requirements of the standard.=0A= The function reference does not match any of the conditions listed in=0A= Table 16.5.=0A= =0A= The closest case is "initialization of an object in a declaration",=0A= but a procedure pointer is not an object (see 3.42).=0A= =0A= Therefore, a MOLD argument is required.=0A= =0A= However, constraint C813 prohibits a MOLD argument from appearing.=0A= =0A= The same does not apply to default initialization of procedure pointer=0A= components in a derived type definition, as component initialization=0A= appears in Table 16.5.=0A= =0A= Is this irregularity deliberate?=0A= =0A= ANSWER:=0A= =0A= No, this is not deliberate. Table 16.5 should be extended to include=0A= initialization in a procedure declaration statement.=0A= =0A= An edit is provided.=0A= =0A= EDIT to N2218 (Fortran 2023 FDIS):=0A= =0A= [428] 16.9.155 NULL, Result Characteristics, Table 16.5=0A= In the entry "initialization for an object..."=0A= change "object" to "entity", twice, making the whole entry read=0A= "initialization for an entity in a declaration | the entity".=0A= {Subtle but effective.}=0A= =0A= SUBMITTED BY: Robert Corbett & Malcolm Cohen=0A= =0A= HISTORY: 23-233 m231 Submitted=0A= 23-233r1 m231 Revised edit, passed by J3 meeting 231.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/012=0A= TITLE: Coarray correspondence in DEALLOCATE=0A= KEYWORDS: DEALLOCATE, coarray=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= In 9.7.3.2 Deallocation of allocatable variables, paragraph 11=0A= requires that coarray dummy arguments on the active images have=0A= ultimate arguments that are corresponding coarrays.=0A= =0A= However, there appears to be no such requirement for coarray=0A= components of dummy arguments.=0A= =0A= Thus this program appears to be valid (apart from having no=0A= interpretation due to coarray allocation status inconsistency):=0A= =0A= Program trouble=0A= Type t=0A= Real,Allocatable :: c(:)[:]=0A= End Type=0A= Type(t) x,y=0A= Allocate(x(1)[*],y(1)[*])=0A= If (This_Image()=3D=3D1) Then=0A= Call oops(x)=0A= Else=0A= Call oops(y)=0A= End If=0A= Print *,Allocated(x%c),Allocated(y%c)=0A= Sync All=0A= Contains=0A= Subroutine oops(z)=0A= Type(t) :: z=0A= Deallocate(z%c)=0A= End Subroutine=0A= End Program=0A= =0A= Should there be a requirement on coarray components of dummy arguments=0A= in DEALLOCATE?=0A= =0A= There is also an editorial glitch in paragraph 10 where it says that a=0A= coarray does not "become deallocated on an image unless it is=0A= successfully deallocated on all active images", since "it" exists on=0A= only one image (the others being the corresponding coarrays), and "all=0A= active images" includes the image in question, so is circular. Should=0A= this not be corrected?=0A= =0A= ANSWER:=0A= =0A= Yes, this requirement should be explicit.=0A= =0A= Yes, the wording in the last sentence of paragraph 10 is poor, and=0A= should be improved.=0A= =0A= Edits are supplied to address these defects.=0A= =0A= As the question noted, the example is not conforming as it violates=0A= the semantics that corresponding coarrays have the same allocation=0A= status, bounds, etc. on all images on which they are established.=0A= =0A= EDIT to N2218:=0A= =0A= [152] 9.7.3.2 Deallocation of allocatable variables, paragraph 10,=0A= last sentence,=0A= change "it is" to "the corresponding coarrays are",=0A= and insert "other" between "all" and "active",=0A= making that whole sentence read:=0A= "A coarray shall not become deallocated on an image unless the=0A= corresponding coarrays are successfully deallocated on all other=0A= active images in this team."=0A= {Clarify "it" and "all".}=0A= =0A= [152] Same subclause, paragraph 11 beginning "If an allocate-object is=0A= a coarray dummy argument", append new sentence=0A= "If an allocate-object is a coarray subcomponent of a dummy=0A= argument, those components of the ultimate arguments on those=0A= images shall be corresponding coarrays."=0A= {Requirement needed to maintain coarray correspondence semantics.=0A= A "subcomponent" is a component that is an immediate component,=0A= of a component of a subobject.}=0A= =0A= SUBMITTED BY: John Reid & Reinhold Bader=0A= =0A= HISTORY: 23-218 m231 Submitted=0A= 23-243 m231 Revised=0A= 23-243r1 m231 Passed by J3 meeting 231.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/013=0A= TITLE: BOZ literals in interoperable enumerators=0A= KEYWORDS: BOZ, enumerators=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= For Fortran 2023, work item US-23 expanded the contexts in which=0A= BOZ constants were allowed, to include "as the =0A= for a named constant of type INTEGER or REAL,..." (C7119).=0A= 19-256r1 had the primary edits, with 21-101 containing additional=0A= edits not relevant to this paper.=0A= =0A= 19-256r1 contained examples showing use of BOZ constants in=0A= PARAMETER statements, but did not mention interoperable=0A= enumerators, which are "named integer constant[s]" (7.6.1p1).=0A= =0A= Consider the following:=0A= =0A= ENUMERATOR :: FOO =3D Z'123'=0A= =0A= is this conforming in Fortran 2023? Clearly, the intent of US-23=0A= was that it should be, but the syntax rule for is:=0A= =0A= R762 enumerator is named-constant [ =3D scalar-int-constant-expr ]=0A= =0A= Since a BOZ constant has no type (7.7p1), it can't be an integer,=0A= and thus isn't a scalar-int-constant-expr. Was this exclusion=0A= intended? (Note: PARAMETER does not have this issue.)=0A= =0A= ANSWER:=0A= =0A= No - it was intended to allow BOZ constants as the value for=0A= interoperable enumerators just as they are in the PARAMETER=0A= statement. Edits to correct this are provided.=0A= =0A= EDITS to 24-007:=0A= =0A= [7.6.1, 95:18+ Interoperable enumerations and enum types]=0A= =0A= insert after:=0A= R762 enumerator is named-constant [ =3D scalar-int-constant-expr ]=0A= =0A= " or [ =3D ]"=0A= =0A= (The Editor is welcome to substitute an alternate expression of this=0A= definition, such as creating a new term for the initializer.)=0A= =0A= [7.6.1p6, 96:5-9 Interoperable enumerations and enum types]=0A= =0A= In the numbered list following "The enumerator is a scalar named=0A= constant, with the value determined as follows.", make the following=0A= changes.=0A= =0A= Insert after (1):=0A= "(1a) if boz-literal-constant appears, the enumerator has the value=0A= specified by INT(boz-literal-constant, C_INT), where C_INT is from=0A= the intrinsic module ISO_C_BINDING."=0A= =0A= In the current (2) and (3), replace "If scalar-int-constant-expr does=0A= not appear" with "If neither scalar-int-constant-expr nor=0A= boz-literal-constant appears" such that the new list items read:=0A= =0A= (2a) If neither scalar-int-constant-expr nor boz-literal-constant=0A= appears and the enumerator is the first enumerator in enum-def, the=0A= enumerator has the value zero.=0A= (3a) If neither scalar-int-constant-expr nor boz-literal-constant=0A= appears and the enumerator is not the first enumerator in enum-def,=0A= it has the value obtained by adding one to the value of the=0A= enumerator that immediately precedes it in the enum-def.=0A= =0A= [7.7,100:30 Binary, octal, and hexadecimal literal constants]=0A= =0A= In C7119, after "variable of type integer or real"=0A= =0A= insert:=0A= =0A= ", as the value in an "=0A= =0A= SUBMITTED BY: Steve Lionel=0A= =0A= HISTORY: 24-101 m232 Submitted=0A= 24-101r1 m233 Passed by J3 meeting 233.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/015=0A= TITLE: Coindexed objects in structure constructors=0A= KEYWORDS: Pointer component, coindexed object, structure constructor=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= Consider=0A= =0A= TYPE realptrwrap=0A= REAL,POINTER :: p=0A= END TYPE=0A= TYPE t=0A= TYPE(realptrwrap) c=0A= END TYPE=0A= TYPE(realptrwrap) x[*]=0A= TYPE(t) y=0A= REAL,TARGET :: z[*]=0A= =0A= x =3D realptrwrap(z[2]) ! (A) harmful=0A= y%c =3D realptrwrap(z[2]) ! (B) harmful=0A= x =3D realptrwrap(z) ! This assignment is valid and harmless.=0A= y =3D t(x[2]) ! (C) harmful=0A= =0A= (Aside: "harmful" means "copies a pointer from one image to another".)=0A= =0A= The structure constructors in the statements (A) and (B) are invalid,=0A= by combination of=0A= R758 component-data-source is expr=0A= or data-target=0A= or proc-target=0A= C7109 (R758) A data-target shall correspond to a data pointer=0A= component; ...=0A= R1038 data-target is expr=0A= C1029 (R1038) A data-target shall not be a coindexed object.=0A= =0A= However, the statement (C) has the same undesirable effect as (B), but=0A= does not violate those constraints, and thus appears on the face of it=0A= to be a valid statement.=0A= =0A= Statement (C) would, however, be prohibited in a pure procedure, even=0A= though it cannot cause side effects, merely undefined pointers.=0A= =0A= This appears to be inconsistent. Is this deliberate?=0A= =0A= ANSWER:=0A= =0A= This apparent inconsistency was inadvertent.=0A= Edits are provided to correct the issue.=0A= =0A= EDITS to 24-007:=0A= =0A= [93:21+] 7.5.10 Construction of derived-type values,=0A= after the penultimate constraint C7109, insert new=0A= constraint=0A= "C7109a (R758) If is a coindexed object, it shall not have=0A= a pointer component at any level of component selection."=0A= =0A= [93:23-] Same subclause, after NOTE 1, insert new NOTE=0A= "NOTE 1a=0A= Although a coindexed object with a pointer subcomponent is not=0A= the only way for the structure constructor to produce a value=0A= with an undefined pointer subcomponent, copying a pointer from=0A= another image is particularly likely to cause undiagnosed=0A= incorrect results, and thus precluded in this context."=0A= =0A= [34:1+] 4.3.3 Fortran 2018 compatibility, after paragraph 4,=0A= insert new paragraph=0A= "Fortran 2018 permitted a in a structure=0A= constructor to be a coindexed object with a pointer subcomponent.=0A= This document does not permit such usage."=0A= =0A= [35:8+] 4.3.4 Fortran 2008 compatibility, after paragraph 14,=0A= insert new paragraph=0A= "Fortran 2008 permitted a in a structure=0A= constructor to be a coindexed object with a pointer subcomponent.=0A= This document does not permit such usage."=0A= =0A= SUBMITTED BY: Malcolm Cohen=0A= =0A= HISTORY: 24-149 m233 Submitted=0A= 24-149r1 m233 Passed by J3 meeting 233.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= --------------------------------------------------------------------=0A= =0A= NUMBER: F23/016=0A= TITLE: Segments associated with allocation=0A= KEYWORDS: segment, allocate, coarray=0A= DEFECT TYPE: Clarification=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= Is it possible for a coarray to be allocated on an image in the=0A= current team without there being a corresponding allocated coarray on=0A= another active image in the current team?=0A= =0A= For example, consider the program=0A= =0A= PROGRAM ALLOCATION=0A= IMPLICIT NONE=0A= INTEGER :: I=0A= REAL, ALLOCATABLE :: A[:]=0A= ALLOCATE (A[*])=0A= A =3D THIS_IMAGE()=0A= SYNC ALL=0A= DO I =3D 2,THIS_IMAGE()=0A= IF (A[I]/=3DI) WRITE(*,*) "Value incorrect on image", I=0A= END DO=0A= DEALLOCATE (A)=0A= END=0A= =0A= Is it possible that an execution of the IF statement fails because the=0A= coarray A has already been deallocated on image I?=0A= =0A= ANSWER:=0A= =0A= No, it is not possible.=0A= =0A= For the ALLOCATE statement, the standard says=0A= "execution on the active images of the segment (11.7.2) following=0A= the statement is delayed until all other active images in the=0A= current team have executed the same statement the same number of=0A= times in this team."=0A= =0A= That means that after execution of the ALLOCATE statement on an image,=0A= the coarray is allocated on all the images (in the team).=0A= =0A= For the DEALLOCATE statement, the standard says=0A= "When a statement that deallocates a coarray or an object with a=0A= coarray potential subobject component is executed, there is an=0A= implicit synchronization of all active images in the current=0A= team."=0A= It then goes on to say=0A= "A coarray shall not become deallocated on an image unless it is=0A= successfully deallocated on all active images in this team."=0A= =0A= That means that the DEALLOCATE statement cannot actually deallocate a=0A= coarray on the executing image until all other active images have=0A= reached that DEALLOCATE and confirmed that they can deallocate their=0A= corresponding coarray.=0A= =0A= Furthermore,=0A= "execution on the active images of the segment (11.7.2) following=0A= the statement is delayed until all other active images in the=0A= current team have executed the same statement the same number of=0A= times in this team"=0A= means that after the DEALLOCATE statement execution is complete on one=0A= image, the coarray is unallocated on all active images.=0A= =0A= EDIT to 24-007.=0A= =0A= None.=0A= =0A= SUBMITTED BY: Reinhold Bader=0A= =0A= HISTORY: 24-145 m233 Submitted=0A= 24-145r1 m233 Revised, passed by J3 meeting 233.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/017=0A= TITLE: CFI_establish nonallocatable nonpointer null base address=0A= KEYWORDS: CFI_establish=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= [524:29-31] 18.5.5.5 The CFI_establish function, p3 Description,=0A= states that if CFI_establish is called with the base_addr a null=0A= pointer, and attribute CFI_attribute_other (i.e. not a pointer or=0A= allocatable), it establishes=0A= "a C descriptor that has the attribute CFI_attribute_other but=0A= does not describe a data object".=0A= =0A= However, looking at the definition of base_addr in 18.5.3 [518:15-19],=0A= it does not allow this:=0A= "If the object is an unallocated allocatable variable or a pointer = that=0A= is disassociated, the value is a null pointer; otherwise... {cases=0A= that are not null pointers}."=0A= =0A= Note that CFI_establish is required to follow these rules, as p1=0A= of 18.5.3 states=0A= "The values of these members of a structure of type CFI_cdesc_t=0A= that is produced by the functions and macros specified in this=0A= document... shall have the properties described in this=0A= subclause."=0A= =0A= That is a contradiction, which means that when CFI_establish is called=0A= with CFI_attribute_other, and base_addr is a null pointer, the program=0A= is not standard-conforming and so any behaviour (including memory=0A= corruption or program termination) may result.=0A= =0A= Either this needs to be permitted in 18.5.3, or forbidden in 18.5.5.5.=0A= Permitting it does not seem useful, as there seems to be little or=0A= nothing one could possibly do with such a C descriptor.=0A= =0A= How should this contradiction be resolved?=0A= =0A= ANSWER:=0A= =0A= This should not be permitted, as it is useless.=0A= =0A= Edits are provided to explicitly forbid this.=0A= =0A= EDITS to 24-007:=0A= =0A= [524:15] 18.5.5.5 The CFI_establish function, p2 Formal Parameters,=0A= attribute parameter,=0A= Append new sentence=0A= "If it is CFI_attribute_other, \cf{base_addr} shall not be a null=0A= pointer."=0A= =0A= [524:29-31] Same subclause, p3 Description,=0A= After "for an unallocated allocatable"=0A= change the comma to "or",=0A= After "disassociated pointer"=0A= delete ", or is... data object",=0A= making that sentence read=0A= "If \cf{base_addr} is a null pointer, the established C descriptor=0A= is for an unallocated allocatable or a disassociated pointer."=0A= =0A= {J3: The paragraph is a wall of text, so I won't regurgitate it here.}=0A= =0A= {J3: The standard is contradictory here, so no compatibility issue.}=0A= =0A= SUBMITTED BY: Malcolm Cohen=0A= =0A= HISTORY: 24-150 m233 Submitted=0A= 24-150r1 m233 Passed by J3 meeting 233.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F23/018=0A= TITLE: Correspondence of unallocated coarrays=0A= KEYWORDS: corresponding, unallocated, coarray=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 letter ballot=0A= =0A= QUESTION:=0A= =0A= Consider=0A= =0A= Program example=0A= Real,Allocatable :: a[:]=0A= Call sub(a)=0A= Contains=0A= Subroutine sub(x)=0A= Real,Allocatable :: x[:]=0A= Allocate(x[*])=0A= ... do something with A.=0A= End Subroutine=0A= End Program=0A= =0A= According to 5.4.7 paragraph 3 corresponding coarrays have to be=0A= "established (5.4.8)" in a team.=0A= =0A= According to 5.4.8 paragraph 2,=0A= "An unallocated allocatable coarray is not established."=0A= =0A= Therefore the coarray A on image one does not correspond to the=0A= coarray A on any other image.=0A= =0A= However, 9.7.1.2 Execution of an ALLOCATE statement, paragraph 4,=0A= requires=0A= "If the coarray is a dummy argument, the ultimate arguments=0A= (15.5.2.4) on those images shall be corresponding coarrays."=0A= =0A= The program cannot satisfy that requirement, and thus does not=0A= conform to the standard. That makes it impossible to allocate any=0A= allocatable coarray that is a dummy argument.=0A= =0A= Is this intended?=0A= =0A= ANSWER:=0A= =0A= No, this was not intended.=0A= The definition of correspondence in subclause 5.4.7 is incomplete.=0A= =0A= Edits are supplied to make the definition of correspondence complete,=0A= extending it to cover unallocated allocatable coarrays. This let us=0A= simplify and correct the requirements for allocation.=0A= =0A= EDITS to 24-007:=0A= =0A= [49:26] 5.4.7 Coarray, p3,=0A= Change "For each coarray"=0A= to "For each established coarray".=0A= [49:27] After "in which it is established (5.4.8)."=0A= insert new sentence=0A= "For each unallocated coarray, there exists a=0A= corresponding unallocated coarray with the same declared=0A= type, rank, corank, and non-deferred type parameters on=0A= each active image of the current team."=0A= and then end the paragraph (the rest of paragraph becoming a=0A= new paragraph).=0A= [49:27] Insert a new paragraph in between the above insertion and the=0A= rest of what was paragraph 3:=0A= "For a named coarray that is not a dummy argument, its=0A= corresponding coarrays are the ones with the same name in that=0A= scoping unit. For a coarray that is a component at any level of=0A= component selection, its corresponding coarrays are the same=0A= components of the base object that has the same name in that=0A= scoping unit. If a coarray component is a potential subobject=0A= component of an array element, the array element for its=0A= corresponding coarrays has the same position in array element=0A= order on each image."=0A= {Take the correspondence specification from 9.7.1.2 and put it here=0A= where it belongs. Correspondence is not just for ALLOCATE!}=0A= =0A= ***ASIDE:=0A= =0A= This makes paragraph 3 of 5.4.7 into these three paragraphs:=0A= "For each established coarray on an image, there is a corresponding=0A= coarray with the same type, type parameters, and bounds on every=0A= other image of a team in which it is established (5.4.8). For each=0A= unallocated coarray, there exists a corresponding unallocated=0A= coarray with the same declared type, rank, corank, and non-=0A= deferred type parameters on each active image of the current=0A= team.=0A= =0A= For a named coarray that is not a dummy argument, its=0A= corresponding coarrays are the ones with the same name in that=0A= scoping unit. For a coarray that is a component at any level of=0A= component selection, its corresponding coarrays are the same=0A= components of the base object that has the same name in that=0A= scoping unit. If a coarray component is an ultimate component of=0A= an array element, the array element for its corresponding coarrays=0A= has the same position in array element order on each image.=0A= =0A= If a coarray is an unsaved local variable of a recursive=0A= procedure, its corresponding coarrays are the ones at the same=0A= depth of recursion of that procedure on each image."=0A= =0A= ***END ASIDE.=0A= =0A= [49:30] Same subclause, paragraph 4,=0A= After "The set of corresponding"=0A= insert "established",=0A= making the whole sentence read=0A= "The set of corresponding established coarrays on all=0A= images in a team is arranged in a rectangular pattern."=0A= {Unallocated coarrays are not arranged in any pattern.}=0A= =0A= [148:32-40] In "9.7.1.2 Execution of an ALLOCATE statement", replace=0A= the third sentence "If the coarray is a..." to the end of=0A= the paragraph with=0A= "The coarray shall be corresponding (5.4.7) on those images."=0A= {If we got the definition of correspondence right, that is all we need=0A= to say. It would be inappropriate to define what correspondence means=0A= in the middle of the ALLOCATE statement execution.}=0A= =0A= [148:40+] Insert new paragraph=0A= "If an allocation specifies a coarray, the same ALLOCATE statement=0A= shall be executed on every active image of the current team. If=0A= the coarray is an unsaved local variable of a recursive procedure,=0A= the execution of the ALLOCATE statement shall be at the same depth=0A= of recursion of that procedure on those images."=0A= {The first requirement actually follows from the segment rules, but=0A= stating it explicitly means the reader does not have to go off and=0A= prove a theorem. The second requirement is the last sentence of the=0A= existing p4, with slightly simplified wording.}=0A= =0A= SUBMITTED BY: John Reid and Reinhold Bader.=0A= =0A= HISTORY: 23-219 m231 Submitted=0A= 23-219r1 m231 Rejected=0A= 24-146 m233 Revised but not processed=0A= 24-178 m234 Revised again=0A= 24-178r1 m234 Passed by J3 meeting 234.=0A= 25-133 m236 Passed by J3 letter ballot #40=0A= =0A= ----------------------------------------------------------------------=0A= ------=_NextPart_000_0023_01DBC655.6D356FE0--