From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20333 invoked by alias); 20 Jul 2010 21:22:44 -0000 Received: (qmail 20314 invoked by uid 22791); 20 Jul 2010 21:22:43 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Jul 2010 21:22:38 +0000 Received: from [192.168.178.22] (port-92-204-52-63.dynamic.qsc.de [92.204.52.63]) by mx01.qsc.de (Postfix) with ESMTP id 694E63DD28; Tue, 20 Jul 2010 23:22:35 +0200 (CEST) Message-ID: <4C46139B.4070609@net-b.de> Date: Tue, 20 Jul 2010 21:22:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.1.10) Gecko/20100520 SUSE/3.0.5 Thunderbird/3.0.5 MIME-Version: 1.0 To: Daniel Kraft CC: Fortran List , gcc-patches Subject: Re: [Patch, Fortran] More clean-up with try-finally References: <4C435709.9030007@domob.eu> In-Reply-To: <4C435709.9030007@domob.eu> Content-Type: text/plain; charset=ISO-8859-1 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/msg01605.txt.bz2 Daniel Kraft wrote: > I've marked two points in the patch with an XXX comment: First, I > created a new global variable in trans-decl that keeps track of the > currently trans'ed procedure's gfc_symbol (instead of its return > label). I did not find any existing feature to get it, although I may > well image there is one. Did I miss it? I think there is not yet such a variable. > Second, in gfc_trans_return, se.post is added to the code after the > exit jump -- maybe I did completely misunderstand something, but to me > this makes no sense (as it will not be executed anyway); I guess that > this just never really mattered. But I may be wrong -- so can this > line go? And if so, why can we be sure that se.post needs never be > handled? And if I'm wrong, why? I think this line can go. > Ok for trunk once I can bootstrap again and there are no regressions? OK. Thanks for the patch! Tobias