move_alloc for types holding allocatable members

[Steve Kargl]

On Thu, Oct 08, 2015 at 09:06:42PM +0200, Alberto Luaces wrote:
> Steve Kargl writes:
> 
> > On Thu, Oct 08, 2015 at 06:18:19PM +0200, Alberto Luaces wrote:
> >>
> >>   allocate(mytemp(20))
> >>   call move_alloc(mytemp, myarray)
> >>
> >
> > What are you expecting to happen here?
> 
> Hi, Steve.  I wanted to grow the array to 20 elements.  My real code
> works that way, since the length is not known beforehand, and it usually
> gets bigger.  Did I reverse the arguments?
> 

  13.7.82 MOVE_ALLOC (FROM, TO)

  Description. Moves an allocation from one allocatable object to another.

  FROM  may be of any type and rank. It shall be allocatable. It is an
        INTENT(INOUT) argument.


  TO    shall be type compatible (5.1.1.2) with FROM and have the same
        rank.  It shall be allocatable.  It shall be polymorphic if FROM 
        is polymorphic.  It is an INTENT(OUT) argument.  Each nondeferred
        parameter of the declared type of TO shall have the same value
        as the corresponding parameter of the declared type of FROM.

  The allocation status of TO becomes unallocated if FROM is unallocated
  on entry to MOVE_ALLOC.  Otherwise, TO becomes allocated with dynamic
  type, type parameters, array bounds, and value identical to those that
  FROM had on entry to MOVE ALLOC.

  If TO has the TARGET attribute, any pointer associated with FROM on
  entry to MOVE_ALLOC becomes correspondingly associated with TO.  If
  TO does not have the TARGET attribute, the pointer association status
  of any pointer associated with FROM on entry becomes undefined.

  The allocation status of FROM becomes unallocated.


Note that TO is INTENT(OUT).  So,

   The INTENT (OUT) attribute for a nonpointer dummy argument specifies
   that it shall be defined before a reference to the dummy argument is
   made within the procedure and any actual argument that becomes
   associated with such a dummy argument shall be definable.  On invocation
   of the procedure, such a dummy argument becomes undefined except for
   components of an object of derived type for which default initialization
   has been specified.

My interpretation, which may be incorrect, is that

(1) myarray becomes undefined on entry into MOVE_ALLOC.  I'm too
    lazy at the moment to see if undefineness means proper deallocation
    of an allocatable entity.

(2) mytemp is allocated to size 20, but the component 'i' of each entity
    has not been allocated and are undefined.  So, your call to MOVE_ALLOC
    is invalid code because it is going to (implicitly) involve un-
    allocated entities.

So, yes, I believe you have the arguments backwards.

-- 
Steve