From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Wed Jun 3 03:13:11 2020 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 CC47D9DB116; Wed, 3 Jun 2020 03:13:11 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (bvdeuz19.secure.ne.jp [180.222.80.19]) by www.open-std.org (Postfix) with SMTP id 6B4C1358727 for ; Wed, 3 Jun 2020 03:13:07 +0200 (CEST) Received: (qmail 85997 invoked from network); 3 Jun 2020 10:13:04 +0900 Received: from unknown (HELO Maru10) (218.42.159.105) by 0 with SMTP; 3 Jun 2020 10:13:04 +0900 From: "Malcolm Cohen" To: "'WG5 List'" Subject: J3 Fortran interp letter ballot #36 Date: Wed, 3 Jun 2020 10:13:05 +0900 Message-ID: <045b01d63944$22728c20$6757a460$@nag-j.co.jp> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_045C_01D6398F.925A3420" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdY5Q37j5owvNtVhS4eKI94622kZUw== Content-Language: en-gb Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multipart message in MIME format. ------=_NextPart_000_045C_01D6398F.925A3420 Content-Type: multipart/alternative; boundary="----=_NextPart_001_045D_01D6398F.925A3420" ------=_NextPart_001_045D_01D6398F.925A3420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi folks, Attached is J3 Fortran interp letter ballot #36. This is a 30-day letter (email) ballot, containing four interpretation requests previously passed by a J3 meeting. Although this is a formal J3 (PL22.3) ballot, comments/votes from alternates, WG5 members not on J3, and any other interested party, are welcome and will be taken into consideration by J3/Interp. Cheers, -- ..............Malcolm Cohen, NAG Oxford/Tokyo. ------=_NextPart_001_045D_01D6398F.925A3420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

Attached is = J3 Fortran interp letter ballot #36. This is a 30-day letter (email) = ballot, containing four interpretation requests previously passed by a = J3 meeting.

Although this is a formal J3 (PL22.3) ballot, = comments/votes from alternates, WG5 members not on J3, and any other = interested party, are welcome and will be taken into consideration by = J3/Interp.

Cheers,

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

------=_NextPart_001_045D_01D6398F.925A3420-- ------=_NextPart_000_045C_01D6398F.925A3420 Content-Type: text/plain; name="20-130.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="20-130.txt" To: J3 J3/20-130=0A= From: Malcolm Cohen=0A= Subject: J3 Fortran interp letter ballot #36 - due 04-July-2020=0A= Date: 2020-June-02=0A= =0A= Enclosed in the next letter ballot on Fortran interpretations.=0A= =0A= This is a formal letter ballot; only one vote per principal member.=0A= An alternate member may vote if the principal member does not vote;=0A= in any case, comments are welcome from non-voting alternates and from=0A= members of WG5 that are not J3 members, and will be taken into=0A= consideration by J3/interp.=0A= =0A= The rules for interpretation handling by which we operate say:=0A= =0A= o J3 votes on the answer at a J3 meeting; a simple majority=0A= vote marks the answer as "passed by J3 meeting".=0A= =0A= o Between J3 meetings the chair of /interp sends a J3 letter=0A= ballot to J3 to approve interp answers that have been "passed=0A= by J3 meeting". The letter ballot runs for 30 days. An interp=0A= answer passes by a 2/3rds vote; a no vote must be accompanied=0A= by an explanation of the changes necessary to change the member's=0A= vote to yes.=0A= =0A= J3/interp reserves the right to recall an interp answer for=0A= more study even if the answer passes.=0A= =0A= =0A= 4 Fortran interpretations are currently "Passed by J3 meeting" after=0A= J3 meeting #221. This is the letter ballot phase to go from "Passed=0A= by J3 meeting" to "Passed by J3 letter ballot".=0A= =0A= =0A= The following Fortran interpretations are being balloted:=0A= =0A= Yes No Number Title=0A= =0A= --- --- F18/015 Example in C.6.8 is wrong=0A= --- --- F18/016 Host association changes in Fortran 2018=0A= --- --- F18/017 Final subroutine invocation order=0A= --- --- F18/018 Public namelist and private variable=0A= =0A= The text of these interpretations is attached. Each interpretation=0A= 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= above text {not this entire mail message} with any comments to=0A= =0A= j3@j3-fortran.org=0A= =0A= by 11:59:59PM, PDT, Saturday, 04-July-2020, in order to be counted.=0A= =0A= =0A= Thanks /Malcolm=0A= =0A= =0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F18/015=0A= TITLE: Example in C.6.8 is wrong=0A= KEYWORDS: failed images=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 meeting=0A= =0A= The example code for failed images in C.6.8 raises several issues about=0A= its correctness.=0A= =0A= =0A= QUESTION:=0A= =0A= Q1.=0A= =0A= A: In the example in C.6.8, the assignments=0A= me[k] =3D failures(i)=0A= id[k] =3D 1=0A= are made by image 1 and the assignments=0A= me =3D THIS_IMAGE ()=0A= id =3D MERGE (1, 2, me<=3Dimages_used)=0A= are made by image k in unordered segments. Was this intended?=0A= =0A= B: In the example in C.6.8, the assignment=0A= me[k] =3D failures(i)=0A= is made by image 1 and me[k] is referenced on other images in=0A= the FORM TEAM statement in unordered segments. Was this=0A= intended?=0A= =0A= Q2.=0A= =0A= Suppose the program in C.6.8 is executed by 11 images, so 1 is=0A= intended to be a spare. If image 9 in the initial team fails=0A= immediately before it executes the first FORM TEAM statement, then=0A= image 10 in the initial team, which executes FORM TEAM with a=0A= team-number =3D=3D 1 and NEW_INDEX =3D=3D 10 (=3D=3D me), will have = specified=0A= a NEW_INDEX=3D value greater than the number of images in the new=0A= team. Should there be a test for this in the code?=0A= =0A= Q3.=0A= =0A= A: If a replacement image has failed, its image index will be the=0A= value of an element of the array failures, a replacement for it=0A= will be found, and the replacement will be placed in team 1. Was=0A= this intended?=0A= =0A= B: The value of images_used increases each time the setup loop is=0A= executed. However, the array failures will contain the image=0A= indices of all the failed images and allocate all of them fresh=0A= replacements. Was this intended?=0A= =0A= ANSWER:=0A= =0A= 1-A: No. An image control statement that provides segment ordering is=0A= needed.=0A= =0A= 1-B: No.=0A= =0A= 2: This is quite a low-probability event, so exiting with the error=0A= condition seems appropriate.=0A= =0A= 3-A: No.=0A= =0A= 3_B: No. It was intended to allocate replacements only for the newly=0A= failed images.=0A= =0A= Furthermore, the example contains more errors than in the list above.=0A= Therefore an edit is provided that replaces the entire example with=0A= a complete rewrite, involving correction of additional errors, a=0A= better choice of names, and more comments.=0A= =0A= Some of the noteworthy additional changes are:=0A= - declarations separated out and many comments added or changed;=0A= - logical variable START added to distinguish the first execution of=0A= the outer do loop when READ_CHECKPOINT should be false;=0A= - rename ME to LOCAL_INDEX and ID to TEAM_NUMBER;=0A= - code added to calculate the local indices of team 2;=0A= - THEN keyword added to ELSE IF (done) statement. =0A= =0A= EDITS to 18-007r1:=0A= =0A= [543:42-545:17] C.6.8 Example involving failed images,=0A= Replace the entire example with the code below.=0A= Note that many lines and comments are broken to keep=0A= them within 70 columns, these should be joined up or=0A= reformatted in the actual standard.=0A= "=0A= PROGRAM possibly_recoverable_simulation=0A= USE, INTRINSIC :: ISO_FORTRAN_ENV, ONLY:TEAM_TYPE, STAT_FAILED_IMAGE=0A= IMPLICIT NONE=0A= INTEGER, ALLOCATABLE :: failures (:) ! Indices of the failed images.=0A= INTEGER, ALLOCATABLE :: old_failures(:) ! Previous failures.=0A= INTEGER, ALLOCATABLE :: map(:) ! For each spare image k in use, =0A= ! map(k) holds the index of the failed image it replaces.=0A= INTEGER :: images_spare ! No. spare images.=0A= ! Not altered in main loop.=0A= INTEGER :: images_used ! Max index of image in use.=0A= INTEGER :: failed ! Index of a failed image.=0A= INTEGER :: i, j, k ! Temporaries=0A= INTEGER :: status ! stat=3D value=0A= INTEGER :: team_number [*] ! 1 if in working team; 2 otherwise. =0A= INTEGER :: local_index [*] ! Index of the image in the team.=0A= TYPE (TEAM_TYPE) :: simulation_team=0A= LOGICAL :: read_checkpoint ! If read_checkpoint true on=0A= ! entering simulation_procedure, go back to previous check point.=0A= LOGICAL :: done [*] ! True if computation finished on the image.=0A= LOGICAL :: start ! True initially.=0A= =0A= ! Keep 1% spare images if we have a lot, just 1 if 10-199 images,=0A= ! 0 if <10.=0A= images_spare =3D MAX(INT(0.01*NUM_IMAGES()),0,MIN(NUM_IMAGES()-10,1))=0A= images_used =3D NUM_IMAGES () - images_spare=0A= ALLOCATE ( old_failures(0), map(images_used+1:NUM_IMAGES()) )=0A= start =3D .true.=0A= =0A= outer : DO=0A= local_index =3D THIS_IMAGE ()=0A= team_number =3D MERGE (1, 2, local_index<=3Dimages_used)=0A= SYNC ALL (STAT =3D status)=0A= IF (status/=3D0 .AND. status/=3DSTAT_FAILED_IMAGE) EXIT outer=0A= IF (IMAGE_STATUS (1) =3D=3D STAT_FAILED_IMAGE) &=0A= ERROR STOP "cannot recover"=0A= IF (THIS_IMAGE () =3D=3D 1) THEN=0A= ! For each newly failed image in team 1, move into team 1 a=0A= ! non-failed image of team 2.=0A= failures =3D FAILED_IMAGES () ! Note that the values=0A= ! returned by FAILED_IMAGES increase monotonically.=0A= k =3D images_used=0A= j =3D 1=0A= DO i =3D 1, SIZE (failures)=0A= IF (failures(i) > images_used) EXIT ! This failed image and=0A= ! all further failed images are in team 2 and do not matter.=0A= failed =3D failures(i)=0A= ! Check whether this is an old failed image.=0A= IF (j <=3D SIZE (old_failures)) THEN=0A= IF (failed =3D=3D old_failures(j)) THEN=0A= j =3D j+1=0A= CYCLE ! No action needed for old failed image.=0A= END IF=0A= END IF=0A= ! Allow for the failed image being a replacement image.=0A= IF (failed > NUM_IMAGES()-images_spare) failed =3D map(failed)=0A= ! Seek a non-failed image=0A= DO k =3D k+1, NUM_IMAGES ()=0A= IF (IMAGE_STATUS (k) =3D=3D 0) EXIT=0A= END DO=0A= IF (k > NUM_IMAGES ()) ERROR STOP "cannot recover"=0A= local_index [k] =3D failed=0A= team_number [k] =3D 1=0A= map(k) =3D failed=0A= END DO=0A= old_failures =3D failures=0A= images_used =3D k =0A= ! Find the local indices of team 2=0A= j =3D 0=0A= DO k =3D k+1, NUM_IMAGES ()=0A= IF (IMAGE_STATUS (k) =3D=3D 0) THEN=0A= j =3D j+1 =0A= local_index[k] =3D j=0A= END IF=0A= END DO=0A= END IF=0A= SYNC ALL (STAT =3D status)=0A= IF (status/=3D0 .AND. status/=3DSTAT_FAILED_IMAGE) EXIT outer=0A= !=0A= ! Set up a simulation team of constant size.=0A= ! Team 2 is the set of spares, so does not participate.=0A= FORM TEAM (team_number, simulation_team, NEW_INDEX=3Dlocal_index, &=0A= STAT=3Dstatus)=0A= IF (status/=3D0 .AND. status/=3DSTAT_FAILED_IMAGE) EXIT outer=0A= =0A= simulation : CHANGE TEAM (simulation_team, STAT=3Dstatus)=0A= IF (status =3D=3D STAT_FAILED_IMAGE) EXIT simulation=0A= IF (start) read_checkpoint =3D .FALSE.=0A= start =3D .FALSE.=0A= IF (team_number =3D=3D 1) THEN=0A= iter : DO=0A= CALL simulation_procedure (read_checkpoint, status, done)=0A= ! The simulation_procedure:=0A= ! - sets up and performs some part of the simulation;=0A= ! - resets to the last checkpoint if requested;=0A= ! - sets status from its internal synchronizations;=0A= ! - sets done to .TRUE. when the simulation has completed.=0A= IF (status =3D=3D STAT_FAILED_IMAGE) THEN=0A= read_checkpoint =3D .TRUE.=0A= EXIT simulation=0A= ELSE IF (done) THEN=0A= EXIT iter=0A= END IF=0A= read_checkpoint =3D .FALSE.=0A= END DO iter=0A= END IF=0A= END TEAM (STAT=3Dstatus) simulation =0A= =0A= SYNC ALL (STAT=3Dstatus)=0A= IF (THIS_IMAGE () > images_used) done =3D done[1]=0A= IF (done) EXIT outer=0A= END DO outer=0A= IF (status/=3D0 .AND. status/=3DSTAT_FAILED_IMAGE) &=0A= PRINT *,'Unexpected failure',status=0A= END PROGRAM possibly_recoverable_simulation=0A= "=0A= =0A= SUBMITTED BY: John Reid=0A= =0A= HISTORY: 19-182 m219 Submitted=0A= 19-182r3 m219 Revised draft - Passed by J3 meeting=0A= 19-228 m220 Failed J3 letter ballot #35=0A= 20-105 m221 Revised answer - Passed by J3 meeting=0A= =0A= ----------------------------------------------------------------------=0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F18/016=0A= TITLE: Host association changes in Fortran 2018=0A= KEYWORDS: Host association=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 meeting=0A= =0A= QUESTION:=0A= =0A= The default semantics for accessing entities by host association from=0A= an interface body appear to be different in Fortran 2018 than in=0A= Fortran 2008.=0A= =0A= Problem 1:=0A= In Fortran 2008, an interface body that is not a module procedure=0A= interface body cannot access entities in its host by host association=0A= unless an IMPORT statement is present in the interface body. The same=0A= rule applies by default in Fortran 2018 if the interface body is for=0A= an external or dummy procedure, but not if the interface body is for=0A= an abstract interface or a procedure pointer that is not a dummy=0A= procedure pointer (see 8.8 "IMPORT statement" [117:17-19]).=0A= =0A= For example, in=0A= DOUBLE PRECISION X=0A= ABSTRACT INTERFACE=0A= SUBROUTINE SUB(A)=0A= REAL(KIND(X)) A=0A= END SUBROUTINE=0A= END INTERFACE=0A= Fortran 2008 specifies that X is default REAL, and that therefore so=0A= is argument A, but Fortran 2018 specifies that X is accessed by host=0A= association and so argument A is double precision.=0A= =0A= Problem 2:=0A= The Fortran 2008 standard specified that a submodule has access to=0A= host entities, but the Fortran 2018 standard does not specify any=0A= default host association semantics for a submodule (it specifies=0A= IMPORT semantics only for nested scoping units (see 8.8 "IMPORT=0A= statement" [117:23-26]). That makes submodules using host association=0A= not conforming.=0A= =0A= For example, in=0A= MODULE mod=0A= INTERFACE=0A= MODULE SUBROUTINE S=0A= END SUBROUTINE=0A= END INTERFACE=0A= INTEGER,PARAMETER :: WP =3D KIND(0.0)=0A= END MODULE=0A= SUBMODULE (mod) submod=0A= REAL(WP) X=0A= END SUBMODULE=0A= the submodule references WP by host association in Fortran 2008, but=0A= Fortran 2018 does not specify any semantics and so the whole thing is=0A= not conforming.=0A= =0A= Problem 3:=0A= The Fortran 2008 standard specified that generic identifiers were=0A= accessible by host association, but the Fortran 2018 standard specifies=0A= that host association is for named entities.=0A= =0A= For example, in=0A= INTERFACE OPERATOR(.plus.)=0A= PROCEDURE plusfun=0A= END INTERFACE=0A= ...=0A= CONTAINS=0A= SUBROUTINE SUB(a,b,c)=0A= ...=0A= c =3D a.plus.b=0A= Fortran 2018 would not permit access to the user-defined operator.=0A= =0A= Problem 4:=0A= The Fortran 2018 standard specifies that BLOCK constructs access named=0A= entities in their hosts by host association. This makes no sense=0A= because BLOCK constructs already have access to entities in their=0A= hosts through inclusive scoping.=0A= =0A= Were these changes intended?=0A= =0A= ANSWER:=0A= =0A= No, none of these changes were intended.=0A= =0A= Edits are provided to restore the semantics specified in the Fortran=0A= 2008 standard.=0A= =0A= EDITS to 18-007r1:=0A= =0A= [117:18-19] 8.8 IMPORT statement, p2, second sentence,=0A= Replace "interface body for an ... procedure."=0A= with=0A= "interface body that is not a module procedure=0A= interface body."=0A= =0A= making the sentence read=0A= =0A= "This is the default for an interface body that is not=0A= a module procedure interface body."=0A= =0A= [117:25-26] 8.8 IMPORT statement, p4, second sentence,=0A= Change "for a nested scoping unit ... procedure"=0A= to "for a derived-type definition, internal subprogram,=0A= module procedure interface body, module subprogram, or=0A= submodule"=0A= making the sentence read=0A= "This is the default for a derived-type definition,=0A= internal subprogram, module procedure interface body,=0A= module subprogram, or submodule."=0A= =0A= [502:7] 19.5.1.4 "Host association", p1, first sentence=0A= Change "nested scoping unit"=0A= to "derived-type definition, interface body, internal=0A= subprogram, module subprogram, or submodule",=0A= Delete "named",=0A= Making the sentence read=0A= "A derived-type definition, interface body, internal=0A= subprogram, module subprogram, or submodule has access to=0A= entities from its host as specified in 8.8."=0A= =0A= SUBMITTED BY: Robert Corbett=0A= =0A= HISTORY: 19-257 m220 F18/016 Submitted=0A= 19-257r1 m220 Revised draft - Passed by J3 meeting=0A= =0A= ----------------------------------------------------------------------=0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F18/017=0A= TITLE: Final subroutine invocation order=0A= KEYWORDS: FINAL ALLOCATABLE=0A= DEFECT TYPE: Erratum=0A= STATUS: Passed by J3 meeting=0A= =0A= QUESTION:=0A= =0A= Consider=0A= =0A= Module m=0A= Type base=0A= Contains=0A= Final basef=0A= End Type=0A= Type other=0A= Contains=0A= Final otherf=0A= End Type=0A= Type,Extends(base) :: t=0A= Type(other),Allocatable :: comp=0A= Contains=0A= Final tf=0A= End Type=0A= Contains=0A= Subroutine basef(a)=0A= Type(base),Intent(InOut) :: a=0A= Print *,'basef'=0A= End Subroutine=0A= Subroutine otherf(b)=0A= Type(other),Intent(InOut) :: b=0A= Print *,'otherf'=0A= End Subroutine=0A= Subroutine tf(c)=0A= Type(t),Intent(InOut) :: c=0A= Print *,'tf'=0A= End Subroutine=0A= End Module=0A= Program test=0A= Use m=0A= Call sub=0A= Contains=0A= Subroutine sub=0A= Type(t) x=0A= Allocate(x%comp)=0A= End Subroutine=0A= End Program=0A= =0A= When the subroutine is executed, it will finalize X on exit,=0A= so what is the expected output?=0A= =0A= Finalization of X occurs before auto-deallocation of X%COMP;=0A= this follows from 9.7.3.2 paragraph 9.=0A= =0A= According to 7.5.6.2, in sequence=0A= (1) the object's final procedure is invoked, i.e. TF is called,=0A= (2) finalizable components are finalized, i.e. OTHERF is called,=0A= (3) the parent is finalized, i.e. BASEF is called.=0A= And according to 7.5.6.3, deallocating X%COMP finalizes it,=0A= and so=0A= (4) OTHERF is called.=0A= I.e. the output is=0A= TF=0A= OTHERF=0A= BASEF=0A= OTHERF=0A= =0A= However, this violates the principle that you only finalize something=0A= once.=0A= =0A= Q1. Is X%COMP actually finalized twice?=0A= =0A= It could be argued that "finalizing X before deallocating X%COMP"=0A= only puts an order on invocation of TF, and in particular, finalizing=0A= the parent pseudo-component need not precede the deallocation. But=0A= this would still invoke OTHERF twice.=0A= =0A= Q3. Is the auto-deallocation of an allocatable component required to=0A= follow the finalization of other components and the parent=0A= pseudo-component?=0A= =0A= Now consider the case where X%COMP is not allocated (i.e. delete the=0A= ALLOCATE statement). According to 7.5.6.2, it should invoke=0A= (1) TF on X=0A= (2) OTHERF on X%COMP=0A= (3) BASEF on X%BASE=0A= however, as X%COMP is unallocated, the invocation in step (2) does=0A= not conform to the procedure reference requirements, i.e. the program=0A= is not conforming.=0A= =0A= Q2. Is X%COMP required to be allocated when X is finalized?=0A= =0A= DISCUSSION:=0A= =0A= An object is only finalized in situations listed in 7.5.6.3.=0A= Every such situation would also unconditionally deallocate any=0A= allocatable component, and if that component were finalizable,=0A= such deallocation would also unconditionally finalize the=0A= component (* except for intrinsic assignment, where a previous=0A= interpretation added an exclusion).=0A= =0A= Therefore it seems to be broken to finalize any allocatable component=0A= during finalization of the object it is contained in, as either it=0A= will be non-conforming, or will be finalized twice (* except for the=0A= previously-added exception).=0A= =0A= The design where allocatable entities are finalized at the time of=0A= deallocation would seem to be simpler, easier to understand, and less=0A= buggy.=0A= =0A= Perhaps the finalization of allocatable components in 7.5.6.2 step=0A= (2) should be removed, and the exclusion for intrinsic assignment for=0A= deallocation-finalization should also be removed?=0A= =0A= ANSWER:=0A= =0A= A1. No object should be finalized twice.=0A= A2. No, a finalizable allocatable component should not be required to=0A= be allocated when its containing object is finalized.=0A= =0A= The inclusion of allocatable components in 7.5.6.2 step (2) is an=0A= error in the standard, and the intrinsic assignment exception for=0A= finalization on deallocation is likewise an error.=0A= =0A= Edits are provided to correct these errors.=0A= =0A= A3. An allocatable component should be able to be finalized as soon=0A= as the object's final subroutine returns, i.e. there should be no=0A= requirement on the processor to produce a particular invocation=0A= order here.=0A= =0A= The ambiguity in whether component deallocation and component=0A= finalization should be ordered is inadvertent. An edit is provided=0A= to remove any implication that these need to have a specific order.=0A= =0A= EDITS to 18-007r1:=0A= =0A= [80:9] 7.5.6.2 The finalization process, p1, item (2),=0A= "All finalizable" -> "All nonallocatable finalizable".=0A= {Remove redundant finalization.}=0A= =0A= [80:22] 7.5.6.3 When finalization occurs, p2,=0A= After=0A= "unless it is the variable in an intrinsic assignment statement"=0A= Delete "or a subobject thereof".=0A= {Remove allocatable component exclusion in intrinsic assignment.}=0A= =0A= [137:28] 9.7.3.2 Deallocation of allocatable variables, p9,=0A= Change "that object is finalized"=0A= To "any final subroutine for that object is executed",=0A= Making the whole paragraph read=0A= "If an allocatable component is a subobject of a finalizable=0A= object, any final subroutine for that object is executed before=0A= the component is automatically deallocated."=0A= =0A= SUBMITTED BY: Malcolm Cohen=0A= =0A= HISTORY: 20-117 m221 F18/017 Submitted - Passed by J3 meeting=0A= =0A= ----------------------------------------------------------------------=0A= ----------------------------------------------------------------------=0A= =0A= NUMBER: F18/018=0A= TITLE: Public namelist and private variable=0A= KEYWORDS: NAMELIST PUBLIC PRIVATE=0A= DEFECT TYPE: Clarification=0A= STATUS: Passed by J3 meeting=0A= =0A= QUESTION:=0A= =0A= Consider=0A= =0A= Module m1=0A= Real,Public :: x=0A= End Module=0A= Module m2=0A= Use m1=0A= Private x=0A= Namelist/nml/x=0A= End Module=0A= =0A= On the face of it, module M2 appears to violate=0A= C8105 (R868) A namelist-group-object shall not have the PRIVATE=0A= attribute if the namelist-group-name has the PUBLIC attribute.=0A= as the local X indeed has the PRIVATE attribute. On the other hand,=0A= it is just a local name for the remote X which is PUBLIC, which=0A= raises doubts.=0A= =0A= Comment: This seems to be a very old constraint dating back to when=0A= the standard was much more restrictive about such things.=0A= It is not clear why this should be disallowed.=0A= Even if X were a local variable of M2, it is not clear what=0A= purpose this constraint serves.=0A= =0A= A quick compiler survey revealed that most but not all compilers=0A= think that it is where the variable is defined that matters, i.e.=0A= many accept the example code.=0A= =0A= Q1. Should PRIVATE local variables really be prohibited from a PUBLIC=0A= namelist?=0A= =0A= If the answer to Q1 is yes,=0A= Q2. Is it PRIVATE on the local name that matters, or PRIVATE on the=0A= variable where it is defined?=0A= =0A= COMMENT:=0A= =0A= A NAMELIST statement can contain several namelist-group-names, so it=0A= is also somewhat ambiguous as to which namelist-group-objects this=0A= constraint applies to.=0A= =0A= ANSWER:=0A= =0A= A1. Yes. Although this restriction appears to serve little purpose,=0A= it is a deliberate restriction (which could be lifted in a future=0A= standard).=0A= =0A= A2. It is whether the local name has the PRIVATE attribute that=0A= matters, not where the variable is declared.=0A= =0A= An edit is provided.=0A= =0A= EDIT to 18-007r1:=0A= =0A= [119:8-9] 8.9 NAMELIST statement, C8105,=0A= After "PRIVATE attribute" insert "in the local scope",=0A= and change "the namelist-group-name" to "its namelist-group-name",=0A= making the whole constraint read=0A= "C8105 (R868) A namelist-group-object shall not have the PRIVATE=0A= attribute in the local scope if its namelist-group-name=0A= has the PUBLIC attribute."=0A= =0A= SUBMITTED BY: Malcolm Cohen=0A= =0A= HISTORY: 20-127 m221 F18/018 Submitted=0A= 20-127r1 m221 Passed by J3 meeting=0A= =0A= ----------------------------------------------------------------------=0A= =0A= =3D=3D=3DEND=3D=3D=3D=0A= =0A= =0A= ------=_NextPart_000_045C_01D6398F.925A3420--