From janshep@watson.ibm.com Tue Jul 11 05:38:49 1995 Received: from watson.ibm.com by dkuug.dk with SMTP id AA17427 (5.65c8/IDA-1.4.4j for ); Tue, 11 Jul 1995 15:43:23 +0200 Message-Id: <199507111343.AA17427@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4269; Tue, 11 Jul 95 09:42:59 EDT Date: Tue, 11 Jul 95 09:38:49 EDT From: "Janice C. Shepherd ((914) 784-6313)" X-Addr: H2-D52, Hawthorne I tieline 863 To: sc22wg5@dkuug.dk Subject: Defect item 125 X-Charset: ASCII X-Char-Esc: 29 Mallory: Please include this in the x3j3 premeeting. Thanks. Thoughts, comments anyone? Thanks Janice ---------------------------------------------- To: X3J3 From: Janice C. Shepherd Subject: Defect item 125 - Arguments with the TARGET attribute At the Tokyo meeting of WG5 (1995/4/17-21), WG5 decided on a new edit to address the concerns raised in defect items 125 and 196. The edit was given in terms of the Fortran 95 draft standard. This paper addresses that same edit but in terms of Fortran 90. This paper contains the following parts (sorry it is so long): 1) revised version of 125, using edit proposed by WG5 as modified by X3J3 - change bars included 2) concerns I have about this new version of 125 3) an alternate version of 125 - change bars included 4) original version of 125 (for reference purposes). ---------------------------------------- 1) Revised version of 125 ---------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum | STATUS: QUESTION:Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER:Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET | attribute, and is either scalar or is an assumed-shape array. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. | An earlier answer to this defect included different wording for the start of | the second paragraph of edit 3: | "If the dummy argument has the TARGET attribute and the corresponding | actual argument has the TARGET attribute but is not an array section | with a vector subscript:" | and did not include the paragraph: | "If the dummy argument has the TARGET attribute and is an explicit-shape | array or is an assumed-size array then when execution of the procedure | completes, the pointer association status of any pointer that is | pointer associated with the dummy argument is processor dependent." | The earlier version of edit 3, along with edits 1, 2 and 4 were included | in corrigendum 2. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. | If the dummy argument has the TARGET attribute and is either | scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. | If the dummy argument has the TARGET attribute and is an | explicit-shape array or is an assumed-size array then when execution | of the procedure completes, the pointer association status of | any pointer that is pointer associated with the dummy argument is | processor dependent. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 2. | 95- m133 revised response and edits per WG5 N1112. ---------------------------------------- 2) concerns I have about this new version of 125 ---------------------------------------- A. Edit 4 needs to be modified: Edit 4 needs a change corresponding to the change of adding: "and is either scalar or is an assumed-shape array" to edit 3. Specifically the first paragraph of Edit 4 should be: "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute and is either scalar or is an assumed-shape array, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript." B. Conflict between penultimate and ultimate paragraphs of edit 3. Both the penultimate and the ultimate paragraphs of edit 3 deal with examples such as: a dummy argument with the TARGET attribute that is an explicit-shape array and an actual argument without the TARGET attribute. When execution of the procedure completes, does the pointer association status of any pointer that is pointer associated with the dummy argument become processor dependent (as per the penultimate paragraph) or undefined (as per the ultimate paragraph)? I would guess that we intended the latter. This should be made clear. C. Not all the cases are specified by the standard The two issues being discussed in these edits can be summarized as: 1) Do pointers associated with the actual argument become associated with the dummy argument? 2) When execution of the procedure completes, what is the pointer association status of pointers associated with the dummy argument (for those pointers that remain defined)? Let's consider each of the combinations of actual argument and dummy argument that can exist in a program and the response to these two questions: 1) Do pointers associated with the actual argument become associated with the dummy argument? | non-target | scalar target | vector subscript| array (not vector) | actual arg | actual arg | actual arg | target actual arg ----------------------------------------------------------------------- scalar | not | YES | not allowed | not allowed | target | applicable | See: | See: | See: | dummy arg | (n/a) | Edit 3, pg 2 | 12.4.1.1 last pg| Edit 1 | ----------------------------------------------------------------------- assumed- | | | | YES | shape | n/a | not allowed | n/a | See: | target | | See: | | Edit 3, pg 2| dummy arg | | Edit 1 | | | ----------------------------------------------------------------------- explicit- | | | | | shape | n/a | not allowed | | not | target | | See: | n/a | specified! | dummy arg | | Edit 1 | | | ----------------------------------------------------------------------- assumed- | | | | | size | n/a | not allowed | n/a | not | target | | See: | | specified! | dummy arg | | Edit 1 | | | ----------------------------------------------------------------------- 2) When execution of the procedure completes, what is the pointer association status of pointers associated with the dummy argument (for those pointers that remain defined)? | non-target | scalar target | vector subscript| array (not vector) | actual arg | actual arg | actual arg | target actual arg ----------------------------------------------------------------------- scalar | undefined | Remains Assoc.| not allowed | not allowed | target | See: | See: | See: | See: | dummy arg | Edit 3, pg 4| Edit 3, pg 2 |12.4.1.1, last pg| Edit 1 | ----------------------------------------------------------------------- assumed- | undefined | | | Remains | shape |(ranks must | not allowed | undefined | Associated | target | match) | See: | See: | See: | dummy arg |Edit 3, pg 4 | Edit 1 | Edit 3, pg 4 | Edit 3, pg 2| ----------------------------------------------------------------------- explicit- | undefined * | | undefined * | Processor | shape | | not allowed | | dependent | target |See: | See: | See: | See: | dummy arg | Edit 3, pg 4| Edit 1 | Edit 3, pg 4 | Edit 3, pg 3| ----------------------------------------------------------------------- assumed- | undefined * | | undefined * | Processor | size | | not allowed | | dependent | target |See: | See: | See: | See: | dummy arg | Edit 3, pg 4| Edit 1 | Edit 3, pg 4 | Edit 3, pg 3| ----------------------------------------------------------------------- * - Assuming paragraph 4 of Edit 3 applies instead of paragraph 3 (see concern "B" above). My concern is that while the answers to the 2 questions are addressed for almost all combinations of actual and dummy arguments, the first question is not answered for TARGET arrays being passed to explicit-shape or assumed-size TARGET dummy arguments. I've been told that WG5 would like this to be left as processor dependent. If that is the case, the standard should indicate that. D. New edits are needed for section 12.5.2.9 The edits that are included with defect item 81 were written with the assumption that pointers associated with TARGET actual arguments would be associated with the corresponding TARGET dummy arguments. As it is now processor dependent as to whether this is true for dummy arguments that are explicit-shape or assumed-size arrays, the edits in defect item 81 should exclude these cases (ie the restriction of only defining the entity through the dummy argument should apply to TARGET dummy arguments that are explicit-shape or assumed-size arrays). Alternate edits for defect item 81 need to be created. ---------------------------------------- 3) an alternate version of 125 ---------------------------------------- This version addresses my concerns A, B and C. NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum | STATUS: QUESTION:Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER:Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET | attribute, and is either scalar or is an assumed-shape array. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expecte behaviour. One such example is included in the edit to section C.12.8. | An earlier answer to this defect included different wording for the start of | the second paragraph of edit 3: | "If the dummy argument has the TARGET attribute and the corresponding | actual argument has the TARGET attribute but is not an array section | with a vector subscript:" | and did not include the paragraph: | "If the dummy argument has the TARGET attribute and is an | explicit-shape array or is an assumed-size array and the | corresponding actual argument has the TARGET attribute but is | not an array section with a vector subscript: | (1) On invocation of the procedure, whether any pointers | associated with the actual argument become associated | with the corresponding dummy argument is processor dependent. | (2) When execution of the procedure completes, the pointer | association status of any pointer that is pointer associated | with the dummy argument is processor dependent." | An earlier answer to this defect included different wording for the first | paragraph of edit 4. | "When execution of a procedure completes, any pointer that remains | defined and that is associated with a dummy argument that has the | TARGET attribute, remains associated with the corresponding actual | argument if the actual argument has the TARGET attribute and is | not an array section with a vector subscript. | The earlier versions of edits 3 and 4, along with edits 1 and 2 were included | in corrigendum 2. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. | If the dummy argument has the TARGET attribute and is either | scalar or is an assumed-shape array, and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. | If the dummy argument has the TARGET attribute and is an | explicit-shape array or is an assumed-size array and the | corresponding actual argument has the TARGET attribute but is | not an array section with a vector subscript: | (1) On invocation of the procedure, whether any pointers | associated with the actual argument become associated | with the corresponding dummy argument is processor dependent. | (2) When execution of the procedure completes, the pointer | association status of any pointer that is pointer associated | with the dummy argument is processor dependent. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the | TARGET attribute and is either scalar or is an assumed-shape array, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 2. | 95- m133 revised response and edits ---------------------------------------- 4) original version of 125 (for reference purposes). ---------------------------------------- NUMBER: 000125 TITLE: Copy in/copy out of target dummy arguments KEYWORDS: argument - dummy, target, interface - explicit, argument association DEFECT TYPE: Erratum STATUS: Published QUESTION: Previous Fortran standards have permitted copy in/copy out as a valid implementation for argument passing to procedures, as does Fortran 90. Fortran 90 introduces POINTER and TARGET attributes. Sections 12.4.1.1 and C.12.8 indicate that it was intended that copy in/copy out also be a valid implementation for passing an actual argument that has the TARGET attribute to a dummy argument that has the TARGET attribute. The following example demonstrates a case where a copy in/copy out implementation may get different results from an implementation which does not use a copy in/copy out method for such a combination of arguments. POINTER IPTR TARGET I IPTR => I CALL SUB (I, IPTR) ... CONTAINS SUBROUTINE SUB (J, JPTR) POINTER JPTR TARGET J PRINT *, ASSOCIATED (JPTR, J) END SUBROUTINE END Is this a flaw in the standard? ANSWER: Yes, there is a flaw in the standard. The edits supplied disallow copy in/copy out as a valid implementation for passing an actual argument that has the TARGET attribute to a corresponding argument that has the TARGET attribute. Discussion: The changes apply only to target dummy arguments. Without the changes the behaviour of the example in the question would surprise many programmers. Other examples not involving the ASSOCIATED function are also affected by these changes in such a way that they too will have a more expected behaviour. One such example is included in the edit to section C.12.8. EDITS: 1. Section 12.4.1.1, add at the end of the fourth paragraph [173:6], "If the dummy argument has the TARGET attribute and the actual argument has the TARGET attribute but is not an array section with a vector subscript, the dummy and actual arguments must have the same shape." 2. Section 12.4.1.1, fifth paragraph, last sentence [173:10-13] delete, "with a dummy argument of the procedure that has the TARGET attribute or" 3. Section 12.4.1.1, delete the sixth paragraph [173:14-17] and replace with, "If the dummy argument does not have the TARGET or POINTER attribute, any pointers associated with the actual argument do not become associated with the corresponding dummy argument on invocation of the procedure. If the dummy argument has the TARGET attribute and the corresponding actual argument has the TARGET attribute but is not an array section with a vector subscript: (1) Any pointers associated with the actual argument become associated with the corresponding dummy argument on invocation of the procedure. (2) When execution of the procedure completes, any pointers associated with the dummy argument remain associated with the actual argument. If the dummy argument has the TARGET attribute and the corresponding actual argument does not have the TARGET attribute or is an array section with a vector subscript, any pointers associated with the dummy argument become undefined when execution of the procedure completes." 4. Section C.12.8, delete the second paragraph through the end of the section [292:5-37] and replace with "When execution of a procedure completes, any pointer that remains defined and that is associated with a dummy argument that has the TARGET attribute, remains associated with the corresponding actual argument if the actual argument has the TARGET attribute and is not an array section with a vector subscript. REAL, POINTER :: PBEST REAL, TARGET :: B (10000) CALL BEST (PBEST, B) ! Upon return PBEST is associated ... ! with the "best" element of B CONTAINS SUBROUTINE BEST (P, A) REAL, POINTER :: P REAL, TARGET :: A (:) ... ! Find the "best" element A(I) P => A (I) RETURN END SUBROUTINE END When the procedure BEST completes, the pointer PBEST is associated with an element of B. An actual argument without the TARGET attribute can become associated with a dummy argument with the TARGET attribute. This permits pointers to become associated with the dummy argument during execution of the procedure that contains the dummy argument. For example: INTEGER LARGE(100,100) CALL SUB(LARGE) ... CALL SUB() CONTAINS SUBROUTINE SUB(ARG) INTEGER, TARGET, OPTIONAL :: ARG(100,100) INTEGER, POINTER, DIMENSION(:,:) :: PARG IF (PRESENT(ARG)) THEN PARG => ARG ELSE ALLOCATE (PARG(100,100)) PARG = 0 ENDIF ... ! Code with lots of references to PARG IF (.NOT. PRESENT(ARG)) DEALLOCATE(PARG) END SUBROUTINE SUB END Within subroutine SUB the pointer PARG is either associated with the dummy argument ARG or it is associated with an allocated target. The bulk of the code can reference PARG without further calls to the PRESENT intrinsic." SUBMITTED BY: Jon Steidel - X3J3/93-095 HISTORY: 93-095 m124 submitted with draft response and adopted (15-1) 93-111 m125 ballot, returned to subgroup based on Leonard, Maine comments. Problems with placement of edit 1, content of edit 4 93-139r m125 revised response adopted 17-1. 93-255r1 m127 ballot failed 13-10 94-092r1 m128 revised response, approved 11-5 94-116r1 m129 X3J3 ballot failed 10-13 94-177r1 m129 revised response closer to 93-255r1; approved 19-2 94-221 m130 X3J3 ballot, approved 21-2 94-327 m131 WG5 approved, edit changed to reflect change in corrigendum 2.