From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1830 invoked by alias); 26 Jun 2012 15:16:32 -0000 Received: (qmail 1788 invoked by uid 22791); 26 Jun 2012 15:16:27 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 26 Jun 2012 15:16:12 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5QFGB4c022783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Jun 2012 11:16:11 -0400 Received: from [10.3.113.5] ([10.3.113.5]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q5QFGAFh030823; Tue, 26 Jun 2012 11:16:11 -0400 Message-ID: <4FE9D23A.20000@redhat.com> Date: Tue, 26 Jun 2012 15:29:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Richard Guenther CC: Xinliang David Li , GCC Patches , Michael Matz Subject: Re: New option to turn off stack reuse for temporaries References: <4FE26AFC.3000703@redhat.com> <4FE43AFD.6050601@redhat.com> In-Reply-To: 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: 2012-06/txt/msg01694.txt.bz2 On 06/26/2012 04:28 AM, Richard Guenther wrote: > No - the fact that the flag is C++ specific but in common.opt is odd enough > and -ftemp-reuse-stack sounds very very generic - which in fact it is not, > it's a no-op in C. Is there a more formal phrase for the temporary kind that > is affected? Not that I'm aware of. This is a temporary introduced by TARGET_EXPR, which lives until the end of the enclosing CLEANUP_POINT_EXPR. > So - a little kludgy but probably more to what > I'd like it to be would be to move the option to c-family/c.opt enabled only > for C++ and Obj-C++ and export it to the middle-end via a new langhook Hmm, that does seem rather kludgy for something that affects the behavior of middle-end code working on GENERIC. > (the gimplifier code should be in Frontend code that lowers to GENERIC > really and the WITH_CLEANUP_EXPR code should be C++ frontend specific ...). TARGET_EXPR has been a back-end code since the dawn of GCC version control; if it's still only used by the C++ front end I guess it could move to cp-tree.def, but we can't really lower it until gimplification time because we need to strip away enclosing COMPOUND_EXPRs and such so we can see that it's on the RHS of an initialization and optimize away the temporary in that case. And now that GIMPLE isn't a subset of GENERIC, we can't just use the gimplifier at genericization time. And I'd rather not duplicate the entire gimplifier in the front end. Jason