From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80220 invoked by alias); 10 Jul 2015 18:57:17 -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 80199 invoked by uid 89); 10 Jul 2015 18:57:16 -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; Fri, 10 Jul 2015 18:57:16 +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 t6AIvEeF092787 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jul 2015 11:57:14 -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 t6AIvDUf092786; Fri, 10 Jul 2015 11:57:13 -0700 (PDT) (envelope-from sgk) Date: Fri, 10 Jul 2015 18:57: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: <20150710185713.GA92724@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <559FF0DF.8080107@sfr.fr> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg00917.txt.bz2 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." The function not only needs to allocate memory, it needs to assign it a value. In the following, if i <= 0, the function result is not defined. 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 j j = bar( 3); print *, j j = bar(-3); print *, j end if end program test Even if Andre developed a patch to allocate memory in bar() for the i <= 0 case to prevent the segfault, the function must return a value. What should that value be? I suppose one could argue that gfortran should issue a run-time error if it can detect the undefined function result. But may lead to a run-time penalty. -- Steve