From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51948 invoked by alias); 10 Jul 2015 09:44:48 -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 51928 invoked by uid 89); 10 Jul 2015 09:44:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 10 Jul 2015 09:44:46 +0000 Received: from vepi2 ([84.63.202.252]) by mail.gmx.com (mrgmx101) with ESMTPSA (Nemesis) id 0MMoU7-1Z4xkT44HH-008XDZ; Fri, 10 Jul 2015 11:44:35 +0200 Date: Fri, 10 Jul 2015 09:44:00 -0000 From: Andre Vehreschild To: Steve Kargl Cc: GCC-Patches-ML , GCC-Fortran-ML , Paul Richard Thomas Subject: Re: [RFC, Fortran, (pr66775)] Allocatable function result Message-ID: <20150710114432.2adff6d8@vepi2> In-Reply-To: <20150709194131.GA29199@troutmask.apl.washington.edu> References: <20150709122518.08388506@vepi2> <20150709175047.GA70209@troutmask.apl.washington.edu> <20150709194131.GA29199@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-UI-Out-Filterresults: notjunk:1;V01:K0:+wHANDmira4=:8fP9FeXrZqYfYU9lM6IDQx aVB70xJfKvL8XhN506ALhKG6ubSprxHJNVqOwjAjOvGBO3p0JVGMvWWnyMCBn/K8q3tcVqXi6 oIQ+MC5f/x2ElCUmCXJuhtQZnVTBz+46J6JoA9rDettf/jY2jT4wcJcYgoi2mWHGrV9boAix3 bl5kiQpgzP6OZB/qJ9d6Ie3+2enqjVEAljTcbabop/crmhBWUrfbTQv1TeImGx3fNzPA8L4j4 DnryFfOPqIkZ8KIGgP40fy2J7SoKKgxoM4XfxETrO3cTqlECpbb6Z1pQ4kJsWQqJgGzE/K/iY psyWucU16vp1ukiU/8Dk1dwexrBhak3cfKZF3faNW1bzHFGZyneAVLOVbAcYOV7YWf55bmJ25 0uNKc4hehvtnr0Er5VU4cNEENf/Tsn1cOMguxWRTSgLdbOL4CJpGtZA3RerGRtTs0M/dJv+Cl soqPRcBJtUT4GqwWTcKbuWKXovQEPq+r3dcjHS7sBhBxNkZ3p35YvHlYLLhxXED/ddCLUh98b maYEhkp+UbGEtp23qnb25E7WZSff9HJ2KqY/gQCf9MkSa/gfvSXmyKR2jvnESSM83l4yDPGaf p0iObZn+OZNNJsM1hDBNMy1f+y1r7EbUxWFKXEU7N+oq+MX7DWEktUELG5hQSlKBXYp/J1Dk0 u/xoREeuX9Fluy6zaEHRY/wKXcLHibmKY87GUYR0IGS/Uxxs8B5H1BcviTZJ/c6iHNyo= X-SW-Source: 2015-07/txt/msg00860.txt.bz2 Hi all, 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