From jkr@jkr.cc.rl.ac.uk Mon May 14 14:09:29 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id OAA39586 for ; Mon, 14 May 2001 14:09:29 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id NAA01555 for ; Mon, 14 May 2001 13:09:51 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id NAA12996 for SC22WG5@dkuug.dk; Mon, 14 May 2001 13:11:59 +0100 (BST) Date: Mon, 14 May 2001 13:11:59 +0100 (BST) From: John Reid Message-Id: <200105141211.NAA12996@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Interp F90/204 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" WG5, Here is a revision of my paper. Any comments before I send this to J3? Cheers, John. J3/01-xxx Date: 9 May 2001 To: J3 From: John Reid Subject: Interpretation F90/000204 (Meaning of "same variable" description of MVBITS) Here are two new draft responses. I have altered the section number in the question to that of the Fortran 95 standard. The old answer was . These are entirely new. There are two according to whether statements such as CALL MVBITS(DATA(1:2),2,2,DATA(2:3),0) where there is a partial overlap between the FROM and TO arguments are disallowed or allowed. The view that I take is that to allow this would be a change to the standard since DATA(1:2) is certainly not the same variable as DATA(2:3), but I have tried to faithfully present the alternative view that the intention was to have a facility similar to that of default assignment. Note that if the above statement is not allowed, the user can still get the effect of assignment with the statement CALL MVBITS((DATA(1:2)),2,2,DATA(2:3),0) Finally, being more restrictive gives the compiler more scope for optimizing the call. I would like to thank Henry and Kurt for their help. NUMBER: F90/000204 TITLE: Meaning of "same variable" description of MVBITS KEYWORDS: MVBITS DEFECT TYPE: Erratum STATUS: J3 consideration in progress QUESTION: Section 13.14.75 states "TO ... may be the same variable as FROM". Given the following statements, which pairs of variables are the same? INTEGER :: I(10), J(10) EQUIVALENCE (I,J) INTEGER, TARGET :: T(2:11) INTEGER, POINTER :: P1(:), P2(:) P1 => T P2 => T(2:11) I and I P1 and T I(1) and I(1) P1 and T(2:11) I(1:10) and I(1:10) P2 and T I(1:1) and I(1:1:-1) P2 and T(2:11) I and I(1:10) P1 and P2 I and J I(1) and J(1) I(1:10) and J(1:10) I(1:1) and J(1:1:-1) I and J(1:10) ANSWER: The quoted wording makes it clear that calls with the same name for FROM and TO, such as CALL MVBITS(DATA,2,2,DATA,0) ! Overwrite bits 0,1 by bits 2,3 are permitted. It was also intended that associated variables be permitted. The edits correct this. EDITS: In the second line of the final paragraph of subclause 12.7.3 [215,7], change 'may be the same variables' to 'and may be associated scalar variables or array variables all of whose corresponding elements are associated'. In subclause 13.14.75, in the second line of the paragraph that defines the effect of TO [258:21] change 'and may be the same variable as FROM' to 'and may be associated with FROM'. ....................................................................... Alternative response ANSWER: The paragraph on TO contains this sentence [258:24-26]: 'On return, the LEN bits of TO starting at TOPOS are equal to the value that the LEN bits of FROM starting at FROMPOS had on entry.' This was intended to indicate that the semantics of MVBITS would model those of intrinsic assignment; if any elements of the TO and FROM arguments are associated, the effect is as if the FROM were an expression. For example, the statement CALL MVBITS(DATA(1:2),2,2,DATA(2:3),0) is interpreted in the same way as the statement CALL MVBITS((DATA(1:2)),2,2,DATA(2:3),0) The edits make this clear. EDITS: In the first sentence of the final paragraph of subclause 12.7.3 [215,6-7], change 'the actual arguments. . . may be the same variable' to 'the value of the actual argument corresponding to the FROM dummy argument is associated with the corresponding dummy argument'. In subclause 13.14.75, in the second line of the paragraph that defines the effect of TO [258:21] change 'and may be the same variable as FROM' to 'and may be associated with FROM'. ....................................................................... SUBMITTED BY: /jor in response to IBM public comments HISTORY: 95-299 m135 submitted ----- End Included Message -----