From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89218 invoked by alias); 8 Oct 2015 20:34:30 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 89207 invoked by uid 89); 8 Oct 2015 20:34:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 08 Oct 2015 20:34:29 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id t98KYKRF080916 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 8 Oct 2015 13:34:20 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id t98KYJD9080915; Thu, 8 Oct 2015 13:34:19 -0700 (PDT) (envelope-from sgk) Date: Thu, 08 Oct 2015 20:34:00 -0000 From: Steve Kargl To: Alberto Luaces Cc: fortran@gcc.gnu.org Subject: Re: move_alloc for types holding allocatable members Message-ID: <20151008203419.GA80864@troutmask.apl.washington.edu> References: <87y4fdibas.fsf@eps142.cdf.udc.es> <20151008175719.GA80332@troutmask.apl.washington.edu> <87pp0pi3i5.fsf@eps142.cdf.udc.es> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pp0pi3i5.fsf@eps142.cdf.udc.es> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2015-10/txt/msg00045.txt.bz2 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