From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2180 invoked by alias); 2 Jul 2014 22:46:35 -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 2096 invoked by uid 89); 2 Jul 2014 22:46:26 -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:46:24 +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 s62MkNso011115 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 2 Jul 2014 18:46:23 -0400 Received: from stumpy.slc.redhat.com (ovpn-113-161.phx2.redhat.com [10.3.113.161]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s62MkM57030270; Wed, 2 Jul 2014 18:46:22 -0400 Message-ID: <53B48BBE.3050601@redhat.com> Date: Wed, 02 Jul 2014 22:46: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 CC: gcc-patches@gcc.gnu.org Subject: Re: Warn when returning the address of a temporary (middle-end) v2 References: <53B1D0C5.30901@redhat.com> 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/msg00158.txt.bz2 On 06/30/14 15:37, 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. The slot exists, but its contents are undefined. The caller never even knows if the callee ever flushed an object back to those slots or if it did flush back, which objects were flushed and in what state. There was a time when I was pondering using those slots for saving callee saved registers on the PA so that leafs that needed a few stack slots wouldn't need to allococate a new frame, instead it'd just use those convenient 4 words. But this turned out to just not be important and it would totally hose the unwinding mechanisms that were in use on the PA at the time. Jeff