From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13487 invoked by alias); 22 Jul 2010 06:43:03 -0000 Received: (qmail 13460 invoked by uid 22791); 22 Jul 2010 06:43:02 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from taro.utanet.at (HELO taro.utanet.at) (213.90.36.45) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Jul 2010 06:42:56 +0000 Received: from plenty.xoc.tele2net.at ([213.90.36.8]) by taro.utanet.at with esmtp (Exim 4.71) (envelope-from ) id 1ObpUb-0007Hm-BY; Thu, 22 Jul 2010 08:42:53 +0200 Received: from d86-33-197-96.cust.tele2.at ([86.33.197.96] helo=[192.168.1.18]) by plenty.xoc.tele2net.at with esmtpa (Exim 4.71) (envelope-from ) id 1ObpUb-0003ek-5T; Thu, 22 Jul 2010 08:42:53 +0200 Message-ID: <4C47E99B.7060106@domob.eu> Date: Thu, 22 Jul 2010 06:43:00 -0000 From: Daniel Kraft User-Agent: Thunderbird 2.0.0.0 (X11/20070425) MIME-Version: 1.0 To: Tobias Burnus CC: Paul Richard Thomas , Fortran List , gcc-patches Subject: Re: [Patch, Fortran] More clean-up with try-finally References: <4C435709.9030007@domob.eu> <4C46139B.4070609@net-b.de> <4C476770.9060409@net-b.de> In-Reply-To: <4C476770.9060409@net-b.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 X-SW-Source: 2010-07/txt/msg01699.txt.bz2 Tobias Burnus wrote: > Dear Paul, > > Paul Richard Thomas wrote: >>> I think this line can go. >>> >> I do not think that I agree. >> >> I am hard put to do it right now but I rather think that it must be >> possible to generate an integer-scalar-expression that generates a >> post block. It certainly does no harm to leave it in :-) >> > > Thinking about it again, I agree: One needs to take care of se.post. > However, if one simply adds the previous line, the result for the > example below is as follows. First, one returns and then one frees the > memory: > > return __result_bar; > { > void * D.1566; > > D.1566 = (void *) pstr.0; > if (D.1566 != 0B) > { > __builtin_free (D.1566); > } > } > > which doesn't make sense. (Ditto for the old code: The free came after > the "goto __return".) Thus, removing the line does neither harm nor > improve the situation. The real fix is to ensure that the clean up of > "se.post" comes before the "return". Yes, I also agree. Of course, we could build another try-finally there to counter the problem, if se.post is not empty. I can add this, if you agree that it's a reasonable solution. But I've no idea what to do else. BTW, I remember when doing other work at trans-*, that se.post was not used really symetricaly to se.pre at some places (e.g., also just ignored). Daniel -- http://www.pro-vegan.info/ -- Done: Arc-Bar-Cav-Ran-Rog-Sam-Tou-Val-Wiz To go: Hea-Kni-Mon-Pri