From jls@juniper.cray.com Tue Feb 22 18:35:35 1994 Received: from cray.com (timbuk.cray.com) by dkuug.dk with SMTP id AA02824 (5.65c8/IDA-1.4.4j for ); Wed, 23 Feb 1994 07:36:01 +0100 Received: from juniper.cray.com by cray.com (Bob mailer 1.2) id AA05241; Wed, 23 Feb 94 00:35:55 CST Received: from [128.162.96.40] (sfwga1.cray.com) by juniper.cray.com id AA10332; 4.1/CRI-5.6; Wed, 23 Feb 94 00:35:38 CST Date: Wed, 23 Feb 94 00:35:35 CST Message-Id: <9402230635.AA10332@juniper.cray.com> X-Sender: jls@juniper.cray.com (Unverified) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Dr.J.L.Schonfelder" , SC22WG5@dkuug.dk (SC22/WG5 members) From: jls@juniper.cray.com Subject: Re: (SC22WG5.503) Re: (x3j3.1994-89) 006 items X-Charset: ASCII X-Char-Esc: 29 We have been beating this one around for a year and a half. This intrepretation affects several other interpretation responses. We attempted an edit that removed copy in/out semantics for TARGETs. It was then discovered that TARGET actual arguments could only be safely passed to assumed shape dummy TARGET arguments (as reshaping an array across a call could not work correctly). Unfortunatly, there is an example in the section notes (appendix C, chapter 12, i believe, but don't have my standard handy) which pretty much spells out that the intent was to allow copy in/out as a valid implementation for passing TARGET actual arguments to TARGET dummy arguments. I did not, nor did Larry understand why this example was added late in the public review cycle, but during processing interpretations in the past few months on POINTER and TARGET issues, it is now apparent why the exmple is there. In short, the intent was to allow copy in/out as a valid implementation for passing TARGETs. I don't agree that this is will lead to a path of least surprise for users of F90, but it is quite clear that this is what the standard intended. For that reason, we have backed down on supporting interpretation responses which try to change this. -jon At 4:30 PM 2/22/94 +0000, Dr.J.L.Schonfelder wrote: >Janice Shepherd wrote > >stuff deleted.... >> >> The status of interpretation 41 will be reset to "X3J3 consideration in >> progress" as it refers to edits in interpretation 125 that no longer >> exist. (It should have had a HOLD on it pending the outcome of 125). >> >stuff deleted.... >> >> NUMBER: 000125 >> TITLE: Copy in/copy out of target dummy arguments >> KEYWORDS: argument - dummy, target, interface - explicit, association >> DEFECT TYPE: Erratum >> STATUS: X3J3 draft response >> >> 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 dummy arguments that have 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 passing arguments that have the TARGET attribute. >> >> 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 intent of the standard >> was to allow copy in/copy out but not to require it. The edit supplied >> clarifies this intent. >> >> Discussion: The changes apply only to target dummy arguments. >> >> REFERENCES: ISO/IEC 1539:1991 (E) sections 12.4.1.1, and C.12.8. >> >> EDITS: >> >> 1. In section 12.4.1.1, in the paragraph that starts "If the actual >> argument has the TARGET attribute," [173:14] >> change "do not become" >> to "do not necessarily become" >> >> 2. In section 12.4.1.1, in the paragraph that starts "If the actual >> argument has the TARGET attribute," add to the end of the first >> sentence [173:16] >> "that is, whether the pointers associated with the actual argument >> become associated with the dummy argument is processor >> dependent." >> >> SUBMITTED BY: Jon Steidel - X3J3/93-095 >> LAST SIGNIFICANT CHANGE: 93-11-12 000125 ballot failed >> HISTORY: X3J3/93-095 m124 submitted with draft response and adopted (15-1) >> X3J3/93-111 ballot, returned to subgroup based on Leonard, Maine >> comments. Problems with placement of edit 1, content of >> edit 4 >> X3J3/93-139r m125 revised response adopted 17-1. >> X3J3/93-255r1 m127 ballot failed 13-10 >> X3J3/94-092r1 m128 revised response, approved 11-5 >I remain very seriously unhappy about this interpretation. I believe we >have a mess in this area. A strict interpretation of one section >of the book would indicate that the above is(was) the intention, but given >that: >a) we have a requirement that if TARGET is specified for the dummy, the > actual argument must have the target attribute. >b) we require intefaces to be explicit if the dummy argument is a target >we clearly intended target arguments to be handled differently from normal >variables. It was and is my belief that this was done to ensure that for >target arguments the passing method would be by reference not by value and that >the association between the targets and any pointers would in fact be preserved >across the call boundary. I do not believe it was the intention to allow >copy in/copy out semantics in this case. >The above interpretation is guaranteed to produce maximum surprise for the >user. That we have a flaw in the standard I am convinced is true, and it is >a flaw that we need to fix. The above is not a fix it compounds the flaw by >codifying the illdefined and unpredictable. >With this interpretation I cannot make any assumptions about the state of any >pointer dummy arguments to procedures with target dummy arguments and any >associations that existed before or after a call to such a procedure. >The association status of the pointer actual argument after a call is >machine dependent. This is seriously unhelpful and not what a responsible >standard should be defining. >I would like to see this issue revisited and the outcome changed. >-- >Dr.J.L.Schonfelder >Director, Computing Services Dept. >University of Liverpool, UK >Phone: +44(51)794 3716 >FAX : +44(51)794 3759 >email: jls@liv.ac.uk