[J3] [EXTERNAL] Re: Changing address of an allocatable on assignment when shapes match

[Bill Long]

Must be an interesting decision calculation to recommend  that moving the data in memory is more optimal than leaving it in place. Besides, the example program consisted on only a main program, and all of the variables declared  in the main program have the SAVE attribute.  So I don’t think mentioning SAVE contributes much to the discussion of this example. 

I suspect the real issue is that the original specification in an old standard was not careful about including the list of conditions that require deallocation, and the general scheme was to always deallocate, and then allocate.  This is why, before F2008 some compilers had command line switches to not deallocate/allocate variables in an assignment. (Because it caused a performance nightmare in old cods where the array sizes always matched anyway.)

Cheers,
Bill

> On Aug 24, 2019, at 9:48 AM, Robert Corbett via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> To be clear, in the Sun/Oracle implementation, the intrinsic assignment does not cause the allocatable variable to be deallocated in the sense that the standard uses the term.  The data that constitutes the value of the variable moves to a different location in memory, but the variable is not deallocated and then allocated in the sense of the Fortran standard.  The Fortran standard does not specify the particulars of how memory is used to implement the semantics specified by the standard.
> 
> The idea that a variable might be at different locations at different times is not new.  Some FORTRAN 77 compilers implemented SAVE semantics by keeping a copy of the values of local variables in static locations across calls, but on the stack or even in registers during execution of the procedure to which they are local.  The addition of pointers causes problems for such implementations, but TARGET takes care of that.
> 
> Bob Corbett
> 
>> On Aug 24, 2019, at 12:43 AM, Van Snyder via J3 <j3 at mailman.j3-fortran.org> wrote:
>> 
>>> On Sat, 2019-08-24 at 14:29 +0900, Malcolm Cohen via J3 wrote:
>>> The breakage would be if you moved the target, a pointer to that
>>> target would stop working, i.e. the semantics would be broken.
>>> 
>>> Unless, of course, one updates all the associated pointers when you
>>> move a target (like compacting garbage collectors do).
>> 
>> As Malcolm pointed out, the deallocation before the revised allocation
>> causes all associated pointers to become undefined. The reallocation is
>> fine and standard conforming, even if the <variable> has the TARGET
>> attribute. What's not allowed is using a formerly associated pointer
>> after it becomes undefined -- no matter how it became undefined.
>> 
>> There might be some ambiguity because the standard lists the conditions
>> under which the <variable> is reallocated during assignment, but it
>> doesn't say "and otherwise it shall not be reallocated." That seems to
>> be easier to remedy than messing with the relationship between the
>> TARGET attribute and an allocatable <variable> in an assignment
>> statement.
>> 
>>> 
>>> Cheers,
>>> 
>>> From: Vipul Parekh via J3 
>>> Sent: Saturday, August 24, 2019 12:14 PM
>>> To: General J3 interest list 
>>> Cc: Vipul Parekh 
>>> Subject: Re: [J3] [EXTERNAL] Re: Changing address of an allocatable on
>>> assignment when shapes match
>>> 
>>> I couldn't understand the statement, "In general, it would not be
>>> conforming to do the reallocation if the allocatable array has the
>>> TARGET attribute, as this would break the Fortran pointer association
>>> semantics" - can someone please point me to the relevant section(s)
>>> (and paragraph(s)) in the standard that might explain it for me?
>>> 
>>> Thanks,
>>> Vipul Parekh
>>> 
>>> 
>>> On Fri, Aug 23, 2019 at 9:16 PM Malcolm Cohen via J3
>>> <j3 at mailman.j3-fortran.org> wrote:
>>>> 
>>>> We do say so! We state precisely when “reallocation” happens. It’s
>>> not called “reallocation” either; it is called “deallocating” followed
>>> by “allocating”.
>>>> 
>>>> And “reallocation” is already in the reasons, seeing as how it is
>>> stated as “deallocation”, which is already in the reasons. ..
>>> 
>>> 
>>> 
>>> 
>>> Disclaimer
>>> 
>>> The Numerical Algorithms Group Ltd is a company registered in England
>>> and Wales with company number 1249803. The registered office is:
>>> Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
>>> Please see our Privacy Notice for information on how we process
>>> personal data and for details of how to stop or limit communications
>>> from us.
>>> 
>>> This e-mail has been scanned for all viruses and malware, and may have
>>> been automatically archived by Mimecast Ltd, an innovator in Software
>>> as a Service (SaaS) for business.
>>> 
>>> 
>> 
>> 
> 

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425