(j3.2006) Should Local Variables of Impure Elemental Procedures Have the SAVE Attribute?

[Van Snyder]

On Wed, 2011-10-05 at 14:20 -0700, Bill Long wrote:
> 
> On 10/5/11 3:46 PM, Craig Dedo wrote:
> > Everyone:
> >
> > It appears that there is another oversight in the definition of IMPURE
> > ELEMENTAL procedures. Should impure elemental procedures be allowed to
> > have local variables with the SAVE attribute? If so, what should happen
> > if such procedures are called with array-valued arguments?
> >
> 
> I don't see why definitions of local variables with the SAVE attribute 
> are any worse than, for example, definitions of variables accessed by 
> use association.  Or STOP statements, or any of a long list of PURE 
> restrictions that do not apply for IMPURE procedures.
> 
> Certainly allowing a local variable with the SAVE attribute that is 
> never defined during execution of the procedure is harmless.   Even if 
> it gets defined, as in your example, I don't see a real problem.  If the 
> call arguments are arrays, then the procedure is executed once for each 
> of the elements of the array.  There will be inefficiencies associated 
> with constantly storing the variable to memory, but it should execute 
> correctly.  Execution of an IMPURE elemental with array arguments does 
> not imply that the execution can be done in parallel.

Furthermore, 12.8.2 and 12.8.3 specify that the results are as if the
scalar function or subroutine had been applied in array element order.

> 
> Cheers,
> Bill
> 
> > In thinking this over, it appears that this is another situation where a
> > constraint of PURE procedures should also apply to impure elemental
> > procedures. Are there any possible advantages to allowing impure
> > elemental procedures to have local variables with the SAVE attribute? If
> > they are allowed, what complications could result from such procedures
> > being called with array-valued arguments?
> >
> > This afternoon I wrote up a proposed interpretation. What do others
> > think of this approach? If there are flaws in my approach, what
> > alternatives would you prefer and why?
> >
> > [Begin proposed interpretation request]
> >
> > NUMBER: F08/????
> >
> > TITLE: Local Variables of Impure Elemental Procedures
> >
> > KEYWORDS: IMPURE, ELEMENTAL, SAVE
> >
> > DEFECT TYPE: Erratum ???
> >
> > STATUS: Submitted with proposed answer
> >
> > QUESTIONS:
> >
> > Consider the following impure elemental subroutine:
> >
> > Impure Elemental Subroutine Swap_DP ( R1, R2 )
> >
> > Use, Intrinsic :: ISO_Fortran_Env
> >
> > Implicit None ! Force explicit declaration of all data objects.
> >
> > ! Declare subroutine arguments.
> >
> > Real (Kind=Real64), Intent (InOut) :: R1, R2
> >
> > ! Declare local variables.
> >
> > Real (Kind=Real64), Save :: Temp
> >
> > ! Execution starts here.
> >
> > Temp = R1
> >
> > R1 = R2
> >
> > R2 = Temp
> >
> > End Subroutine Swap_DP
> >
> > Q1. Was it intended to be standard-conforming to allow impure elemental
> >
> > procedures to have local variables with the SAVE attribute?
> >
> > Q2. If it is standard-conforming, what should happen if an impure elemental
> >
> > procedure is called with array-valued arguments with the same shape and the
> >
> > impure elemental procedure has local variables with the SAVE attribute?
> >
> > ANSWERS:
> >
> > A1.
> >
> > This was not intended to be standard-conforming. Omission of the
> >
> > requirement for non-saved local variables in impure elemental procedures
> >
> > was inadvertent. An edit is supplied to correct this oversight.
> >
> > A2.
> >
> > There could be serious complications if the SAVE attribute is allowed for
> >
> > local variables of impure elemental procedures. Therefore, local variables
> >
> > in such procedures should not have the SAVE attribute.
> >
> > EDITS to 11-007r1:
> >
> > [314:7] Insert new constraint at the end of 12.8.1
> >
> > "C1290b A local variable of an elemental subprogram, or of a BLOCK construct
> >
> > within an elemental subprogram, shall not have the SAVE attribute."
> >
> > SUBMITTED BY:
> >
> > Craig T. Dedo
> >
> > 17130 Burleigh Place
> >
> > PO Box 423
> >
> > Brookfield, WI 53008-0423
> >
> > USA
> >
> > HISTORY: 11-??? m196 F08/???? submitted with proposed answer
> >
> > [End of proposed interpretation request]
> >
> > Sincerely,
> >
> > *Craig T. Dedo*
> >
> > 17130 W. Burleigh Place
> >
> > P. O. Box 423 Mobile Phone: (414) 412-5869
> >
> > Brookfield, WI 53008-0423 E-mail: <craig at ctdedo.com
> > <mailto:craig at ctdedo.com>>
> >
> > USA
> >
> > Linked-In: http://www.linkedin.com/in/craigdedo
> >
> 
> -- 
> Bill Long                                           longb at cray.com
> Fortran Technical Support    &                 voice: 651-605-9024
> Bioinformatics Software Development            fax:   651-605-9142
> Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3