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

[Rasmussen, Craig E]

I agree with Bill.  Since the elements of the array are executed in array element order, the result is well defined.  I think OpenMP even has syntax for this, if I understand OMP (which I don't) there are thread -private variables and thread-shared (?) variables, the thread-shared variables would act like SAVE?

-craig


On Oct 5, 2011, at 3:20 PM, 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.
> 
> 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