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

Bill Long longb
Wed Oct 5 17:20:31 EDT 2011



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.

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





More information about the J3 mailing list