From owner-hpff-interpret Tue Apr 2 13:47:26 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id NAA03070 for hpff-interpret-out; Tue, 2 Apr 1996 13:47:26 -0600 (CST) Received: from VNET.IBM.COM (vnet.ibm.com [199.171.26.4]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id NAA03064 for ; Tue, 2 Apr 1996 13:47:17 -0600 (CST) Received: from TOROLAB by VNET.IBM.COM (IBM VM SMTP V2R3) with BSMTP id 3644; Tue, 02 Apr 96 14:46:25 EST Received: by TOROLAB (XAGENTA 4.0) id 1201; Tue, 2 Apr 1996 14:31:24 -0500 Received: by twinpeaks.torolab.ibm.com (AIX 3.2/UCB 5.64/4.03) id AA20425; Tue, 2 Apr 1996 14:28:41 -0500 From: (Henry Zongaro) Message-Id: <9604021928.AA20425@twinpeaks.torolab.ibm.com> Subject: Re: hpff-interpret: INDEPENDENT To: jenhel@marin.ntnu.no (Jens Helmers) Date: Tue, 2 Apr 1996 14:28:40 -0500 (EST) Cc: hpff-interpret@cs.rice.edu In-Reply-To: <199603280956.AA047167008@klipper.marina.unit.no> from "Jens Helmers" at Mar 28, 96 10:56:48 am X-Mailer: ELM [version 2.4 PL24alpha3] Content-Type: text Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Hi Jens, > Is this a legal use of INDEPENDENT & NEW ??? > > REAL x, y(n) > > !HPF$ INDEPENDENT, NEW(i) > DO i = 1, n > x = x + y(i) ! Clumsy way to calculate: x=SUM(y) > END DO > > > Jens Helmers, > jenhel@marin.unit.no This is not a legal use of INDEPENDENT, unless n <= 1. When the INDEPENDENT directive appears before a DO, it asserts to the compiler that (among other things) two iterations of the DO will not assign to the same atomic object. Here, the assignment to x violates that condition, unless n is less than or equal to 1. A proposal that will appear in the HPF 2.0 document will permit some DO loops which perform intrinsic reduction operations to be marked as INDEPENDENT, like so: REAL x, y(n) x = 0.0 !HPF$ INDEPENDENT, NEW(i), REDUCTION(x) DO i = 1, n x = x + y(i) END DO Thanks, Henry --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe --------------------------------------------------------------------------- From owner-hpff-interpret Tue Apr 30 14:05:33 1996 Received: (from daemon@localhost) by cs.rice.edu (8.7.1/8.7.1) id OAA07437 for hpff-interpret-out; Tue, 30 Apr 1996 14:05:33 -0500 (CDT) Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by cs.rice.edu (8.7.1/8.7.1) with SMTP id OAA07429 for ; Tue, 30 Apr 1996 14:05:26 -0500 (CDT) Received: from mpsg.hpc.pko.dec.com by mail13.digital.com (5.65v3.2/1.0/WV) id AA12833; Tue, 30 Apr 1996 14:56:07 -0400 Received: by mpsg.hpc.pko.dec.com; id AA17664; Tue, 30 Apr 1996 15:03:37 -0400 From: offner@hpc.pko.dec.com (Carl Offner) Received: by hardy.hpc.pko.dec.com; (5.65v3.2/1.1.8.2/01Nov94-0839AM) id AA08901; Tue, 30 Apr 1996 14:56:02 -0400 Date: Tue, 30 Apr 1996 14:56:02 -0400 Message-Id: <9604301856.AA08901@hardy.hpc.pko.dec.com> To: hpff-interpret@cs.rice.edu Subject: hpff-interpret: More on CCI #57 Sender: owner-hpff-interpret Precedence: bulk --------------------------------------------------------------------------- hpff-interpret@cs.rice.edu is a mailing list for corrections, clarifications, and interpretations related to High Performance Fortran. Instructions for adding or deleting yourself from this list appear at the bottom of this message. --------------------------------------------------------------------------- Concerning CCI #57: After thinking about this matter some more, I am withdrawing whatever remaining objections I had to the suggestion that was made. (I had originally felt that allowing HPF_LOCAL subprograms to take anything other than assumed-shape arguments in any circumstance would be fighting the spirit of what an HPF_LOCAL is. However, the more I think about this, the less certain I am on this point.) Therefore, I would support the following interpretation: An array dummy argument of an HPF_LOCAL subprogram does not have to be assumed-shape if the subprogram is only called from other HPF_LOCAL subprograms. Perhaps this could be said more generally: the restrictions on calling an HPF_LOCAL subprogram apply only to HPF_LOCAL subprograms called from HPF. --Carl Offner --------------------------------------------------------------------------- To (un)subscribe to this list, send mail to hpff-interpret-request@cs.rice.edu. Leave the subject line blank, and in the body put the line (un)subscribe ---------------------------------------------------------------------------