From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111922 invoked by alias); 10 Jul 2015 16:44:16 -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 111903 invoked by uid 89); 10 Jul 2015 16:44:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,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 16:44:14 +0000 Received: from [192.168.0.4] ([84.63.202.252]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M2cDB-1YuQ3z0uaj-00sOLC; Fri, 10 Jul 2015 18:44:10 +0200 In-Reply-To: <559FF0DF.8080107@sfr.fr> 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=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC, Fortran, (pr66775)] Allocatable function result From: Andre Vehreschild Date: Fri, 10 Jul 2015 16:44:00 -0000 To: Mikael Morin ,Steve Kargl CC: GCC-Patches-ML ,GCC-Fortran-ML ,Paul Richard Thomas Message-ID: X-UI-Out-Filterresults: notjunk:1;V01:K0:LXiwzCO8NJE=:RvOvCZSvKA0lNnFbnLS+Ko FcznbgK3g3izjCdUmfAb1iKwP16OnZMUgCBEEe1DXIQZCgxJ2VYjjXXBlDlFOLjr5XMwOykT6 hJCqJKkJ5ZNerOMEXOI36/oLfPjQdKPB47lGHIvaFGF09CtWronixv/H4DMMvds4ClwYaNGzE t1kpXV5C4a5qd3uEVMSCwlrh6XGJ8QQVdOh79zghaKhWSFq3m6AOHqH6GYaqyTVSIRbIHD4HY wlb9A1LTA5SBmSwAFMae2yLuE/eQ4XjJMlGkpEn28nHeQIcEchX3NYKUroCzfqjXxMaWgKAbE uqRwthO7JZ90eWL0KzHOm0x2574kUVFacY6bSqbAId4iMG9qWlORLDmGWQmZnB1QGVcufj6b1 Dgc9fb2idTsRhgjixy4LQSrQQ8FbmNwUBgtw+rNOOW+kzK08o6dn3J+qYXDXtTVE9Z9wC/for BjFxu6HpWr5u1vQs2vtzQemiqHSCnY8f/fJ/+dKeR/BIL5BJbkqu8QjI+zfDvYjxZBoFSeH43 3nPiYNEPkk1pbEm6gq6iDPKVFJ9CnqfZFnDqHI9Uq6VL37Iq+9C+YbotNiwtIGtE49ktZjrUc KgXfuDR646m3wWCjlXlHF78sviYlprCAW9UejLNuvbU23auoeR6hIKONqeszkEOoGMqauzWeX Nm2vcghJ1SQSbEraXnjN0zigejG+Voq8fGsBuuQ+aLAqPb0Y/lKd0ilAvP3A8DN6KDPQ= X-SW-Source: 2015-07/txt/msg00909.txt.bz2 Hi Mikael, hi all, I only had the chance to check with ifort (different versions; including th= e most recent one) and that compiler is consistent with gfortran as it is n= ow, I.e., the executable segfaults after the function has been called. I am though curious what other compilers opinion on that point is. Regards, Andre Am 10. Juli 2015 18:20:47 MESZ, schrieb Mikael Morin : >Hello all, > >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. >For what it's worth, in my opinion, the handling of allocatable that >was >proposed by Andre makes sense to me. It's consistent with what is done >for derived type assignment, the lhs' allocatable components are >deallocated if their rhs counter part are unallocated. Doing the same >for whole objects would be, well, consistent. >What is done by the other compilers? > >Mikael --=20 Andre Vehreschild * Kreuzherrenstr. 8 * 52062 Aachen Mail: vehre@gmx.de * Tel.: +49 241 9291018