From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10937 invoked by alias); 11 Jul 2015 15:37:21 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 10919 invoked by uid 89); 11 Jul 2015 15:37:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=no version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients 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; Sat, 11 Jul 2015 15:37:20 +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 t6BFbH7R010766 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 11 Jul 2015 08:37:17 -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 t6BFbHYO010765; Sat, 11 Jul 2015 08:37:17 -0700 (PDT) (envelope-from sgk) Date: Sat, 11 Jul 2015 15:37:00 -0000 From: Steve Kargl To: Mikael Morin Cc: Andre Vehreschild , GCC-Patches-ML , GCC-Fortran-ML , Paul Richard Thomas Subject: Re: [RFC, Fortran, (pr66775)] Allocatable function result Message-ID: <20150711153716.GA10645@troutmask.apl.washington.edu> References: <20150709122518.08388506@vepi2> <20150709175047.GA70209@troutmask.apl.washington.edu> <20150709194131.GA29199@troutmask.apl.washington.edu> <20150710114432.2adff6d8@vepi2> <20150710134121.GA91910@troutmask.apl.washington.edu> <559FF0DF.8080107@sfr.fr> <20150710185713.GA92724@troutmask.apl.washington.edu> <55A0F5E9.2070705@sfr.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55A0F5E9.2070705@sfr.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg00954.txt.bz2 On Sat, Jul 11, 2015 at 12:54:33PM +0200, Mikael Morin wrote: > Le 10/07/2015 20:57, Steve Kargl a ?crit : > > On Fri, Jul 10, 2015 at 06:20:47PM +0200, Mikael Morin wrote: > >> > >> I'm not completely convinced by the standard excerpts that have been > >> quoted about this topic, as they don't have any explicit mention of > >> allocatable variables/expressions. > > > > I did not quote 12.3.3 about "characteristics of function results", > > which mentions the allocatable attribute. But, that is not > > necessarily relevant. The pieces I quoted explicitly states > > > > "On completion of execution of the function, the value returned > > is that of its function result. ... If the function result is > > not a pointer, its value shall be defined by the function." > Yeah, well, if the standard committee had allowed unallocated > allocatable results, they would have put it here together with pointer, > I guess. > >From F95, 6.3.1.1. "An allocatable array that has been allocated by an ALLOCATE statement and has not been subsequently deallocated (6.3.3) is currently allocated and is definable." Note it is "definable". It is not defined. I cannot find a similar statement in F08 due to the massive rewrite of the standard to accommodate new features (e.g., co-arrays and allocation-on-assignment). F08 6.7.1.3 does say The allocation status of an allocatable entity is one of the following at any time. * The status of an allocatable variable becomes "allocated" if it is allocated by and ALLOCATE statement, if it allocated during assignment, or if it is given that status by the intrinsic subroutine MOVE_ALLOC (13.7.118). An allocatable variable with this status my be referenced, defined, or deallocated; ... * An allocatable variable has a status of "unallocated" if it is not allocated. The status of an allocatable variable becomes unallocated if it is deallocated (6.7.3) or if it is given that status by the allocation transfer procedure. So, change my example to what you want module foo contains function bar(i) integer, allocatable :: bar integer, intent(in) :: i if (i > 0) bar = i end function bar end module foo program test use foo integer, allocatable :: j j = bar( 3); if (allocated(j)) print *, j j = bar(-3); if (allocated(j)) print *, j end program test So, it seems you want the allocation status of j in 'j = bar(-3)' to be unallocated due to the "allocation-on-assignment" feature of f08. I'll simply note that *there is no assignment* as bar(-3) does not return an a value, which is required by If the function result is not a pointer, its value shall be defined by the function. So, you want unallocation-on-nonassignment, which is not in the standard. -- steve