From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10410 invoked by alias); 10 Jul 2015 13:41:26 -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 10387 invoked by uid 89); 10 Jul 2015 13:41:25 -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 13:41:24 +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 t6ADfMcX091955 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Jul 2015 06:41:22 -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 t6ADfLfU091954; Fri, 10 Jul 2015 06:41:21 -0700 (PDT) (envelope-from sgk) Date: Fri, 10 Jul 2015 13:41:00 -0000 From: Steve Kargl To: Andre Vehreschild Cc: GCC-Patches-ML , GCC-Fortran-ML , Paul Richard Thomas Subject: Re: [RFC, Fortran, (pr66775)] Allocatable function result Message-ID: <20150710134121.GA91910@troutmask.apl.washington.edu> References: <20150709122518.08388506@vepi2> <20150709175047.GA70209@troutmask.apl.washington.edu> <20150709194131.GA29199@troutmask.apl.washington.edu> <20150710114432.2adff6d8@vepi2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150710114432.2adff6d8@vepi2> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-07/txt/msg00893.txt.bz2 Yes, it should be closed. When I asked you to open it, I thought the issue was a corner case in your patch. -- steve On Fri, Jul 10, 2015 at 11:44:32AM +0200, Andre Vehreschild wrote: > > this means that pr66775 is to be closed as resolved invalid, because the > current implementation is alright, but only the program to compile is garbage. > Ok, suits me. > > - Andre > > On Thu, 9 Jul 2015 12:41:31 -0700 > Steve Kargl wrote: > > > On Thu, Jul 09, 2015 at 08:59:08PM +0200, Andre Vehreschild wrote: > > > Hi Steve, > > > > > > Thanks for your knowledge. Can you support your statement that an > > > allocatable function has to return an allocated object by a part of the > > > standard? I totally agree with you that this code is ill-designed, but IMO > > > is it not the task of the compiler to address ill design. The compiler has > > > to comply to the standard and the standard allows allocatable objects to be > > > unallocated. So why has the result of a function be allocated always? > > > > > > Regards, > > > Andre > > > > > > > I think the following excerpts from F2008 are the relevant > > clauses, especially the 2nd to last sentence in the excerpt > > from 12.6.2.2. > > > > ! 12.5.3 > > ! > > ! When execution of the function is complete, the value of > > ! the function result is available for use in the expression > > ! that caused the function to be invoked. > > ! > > ! 12.6.2.2 > > ! > > ! If RESULT appears, the name of the result variable of the > > ! function is result-name and all occurrences of the function > > ! name in execution-part statements in its scope refer to the > > ! function itself. If RESULT does not appear, the name of the > > ! result variable is function-name and all occurrences of the > > ! function name in execution-part statements in its scope are > > ! references to the result variable. The characteristics (12.3.3) > > ! of the function result are those of the result variable. On > > ! completion of execution of the function, the value returned is > > ! that of its result variable. If the function result is a pointer, > > ! the shape of the value returned by the function is determined by > > ! the shape of the result variable when the execution of the function > > ! is completed. If the result variable is not a pointer, its value > > ! shall be defined by the function. If the function result is a > > ! pointer, on return the pointer association status of the result > > ! variable shall not be undefined. > > > > > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Steve