From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28011 invoked by alias); 2 Jul 2014 22:39: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 27996 invoked by uid 89); 2 Jul 2014 22:39:47 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD 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; Wed, 02 Jul 2014 22:39:45 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s62MdhvC003914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Jul 2014 18:39:44 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-161.phx2.redhat.com [10.3.113.161]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s62MdgRt024697; Wed, 2 Jul 2014 18:39:43 -0400 Message-ID: <53B48A2E.7080904@redhat.com> Date: Wed, 02 Jul 2014 22:39:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Marc Glisse , gcc-patches@gcc.gnu.org Subject: Re: Warn when returning the address of a temporary (middle-end) v2 References: <53B1D0C5.30901@redhat.com> <20140702121904.GI4471@bubble.grove.modra.org> In-Reply-To: <20140702121904.GI4471@bubble.grove.modra.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00157.txt.bz2 On 07/02/14 06:19, Alan Modra wrote: > On Mon, Jun 30, 2014 at 11:37:50PM +0200, Marc Glisse wrote: >> On Mon, 30 Jun 2014, Jeff Law wrote: >> >>> On 06/29/14 03:22, Marc Glisse wrote: >>>> >>>> After looking at PR 61597, I updated the 2 conditions to: >>>> >>>> + if ((TREE_CODE (valbase) == VAR_DECL >>>> + && !is_global_var (valbase)) >>>> + || TREE_CODE (valbase) == PARM_DECL) >>>> >>>> a PARM_DECL is a local variable and returning its address is wrong, >>>> isn't it? >>> Right. It can live in either a caller or callee allocated slot. >> >> The "caller" case scares me a bit. Is it really wrong to return the >> address in that case? The slot still exists after returning if the >> caller is responsible for it. > > At least on powerpc64, which uses a caller allocated parameter save > area, returning the address of something in the parameter save area > merits a warning. The ABIs explicitly state that the parameter save > area is not preserved over function calls. > > Also note that anything left in a caller allocated parameter save area > will potentially be trashed by arguments written for the next call. Similarly for the PA ABIs. If something returned the address of one of those slots, we'd definitely want a warning. I'd be amazed if that wasn't the case for every ABI with a caller allocated parameter save-back area. jeff