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

[Robert Corbett]

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.
>> 
>> 
> 
>