From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28065 invoked by alias); 31 Jul 2014 04:54:25 -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 28050 invoked by uid 89); 31 Jul 2014 04:54:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 31 Jul 2014 04:54:23 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6V4sMTk031459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 31 Jul 2014 00:54:22 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-85.phx2.redhat.com [10.3.113.85]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6V4sMRD007246; Thu, 31 Jul 2014 00:54:22 -0400 Message-ID: <53D9CBFE.9070603@redhat.com> Date: Thu, 31 Jul 2014 04:58:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Marc Glisse , David Malcolm CC: gcc-patches@gcc.gnu.org Subject: Re: Warn when returning the address of a temporary (middle-end) v2 References: <87fvhmllc5.fsf@talisman.default> <1406660283.2134.122.camel@surprise> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg02156.txt.bz2 On 07/30/14 05:54, Marc Glisse wrote: > On Tue, 29 Jul 2014, David Malcolm wrote: > >> On Tue, 2014-07-29 at 19:36 +0200, Marc Glisse wrote: >>> On Sun, 27 Jul 2014, Richard Sandiford wrote: >>> >>>> Marc Glisse writes: >>>>> Hello, >>>>> >>>>> I followed the advice in this discussion: >>>>> https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00269.html >>>>> >>>>> and here is a new patch. I made an effort to isolate a path in at >>>>> least >>>>> one subcase so it doesn't look too strange that the warning is in this >>>>> file. Computing the dominance info just to tweak the warning >>>>> message may >>>>> be a bit excessive. >>>> >>>> How about only calculating it once you've decided to issue a message? >>>> >>>>> + if (always_executed) >>>>> + msg = "function returns address of local variable"; >>>>> + else >>>>> + msg = "function may return address of local variable"; >>>> >>>> I think you need _(...) here, unless some magic makes that >>>> unnecessary now. >>> >>> Current version, which passed bootstrap+testsuite on x86_64-linux-gnu. >>> (the original discussion is at >>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01692.html ) >> >> This is possibly a dumb question, but what happens for a static local, >> rather than an auto local? e.g. >> >> int *f (void) >> { >> static int i; >> return &i; >> } >> >> (e.g. should the test case cover this?) > > New version with a static local variable in the testcase, and without > using build_compound_expr in the C front-end to avoid extra warnings. > > Same ChangeLog, same testsuite results. Approved. Jeff