From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10164 invoked by alias); 19 Feb 2008 01:15:05 -0000 Received: (qmail 10153 invoked by uid 22791); 19 Feb 2008 01:15:04 -0000 X-Spam-Check-By: sourceware.org Received: from wa-out-1112.google.com (HELO wa-out-1112.google.com) (209.85.146.179) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Feb 2008 01:14:47 +0000 Received: by wa-out-1112.google.com with SMTP id m16so3016713waf.20 for ; Mon, 18 Feb 2008 17:14:45 -0800 (PST) Received: by 10.114.79.1 with SMTP id c1mr1344727wab.148.1203383685665; Mon, 18 Feb 2008 17:14:45 -0800 (PST) Received: by 10.115.15.6 with HTTP; Mon, 18 Feb 2008 17:14:45 -0800 (PST) Message-ID: <24b520d20802181714o259570f5qf9020dadd7503fc7@mail.gmail.com> Date: Tue, 19 Feb 2008 01:17:00 -0000 From: "Doug Gregor" To: "Mark Mitchell" Subject: Re: [C++ PATCH] Don't allow taking the address of an rvalue reference (PR c++/35153) Cc: "GCC Patches" In-Reply-To: <47BA2BE2.9020507@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <24b520d20802151248j8cc6547v417f559e6475054b@mail.gmail.com> <47BA2BE2.9020507@codesourcery.com> X-IsSubscribed: yes 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: 2008-02/txt/msg00729.txt.bz2 On Feb 18, 2008 8:07 PM, Mark Mitchell wrote: > Doug Gregor wrote: > > > 2008-02-15 Douglas Gregor > > > > PR c++/35153 > > * typeck.c (build_x_unary_op): Don't allow us to take the address > > of an rvalue that's hiding being an INDIRECT_REF. We can only end > > up triggering that error when we have some kind of rvalue > > reference. > > > > 2008-02-15 Douglas Gregor > > > > PR c++/35153 > > * g++.dg/cpp0x/rref-35153.C: New. > > Why not put this in build_unary_op? That's where we do most of the > other checks -- though, of course, OFFSET_REF and TARGET_EXPR are in > build_x_unary_op, for reasons I don't really understand. I tried putting it in build_unary_op the first time, and.. > So, I think your check should go in build_unary_op -- unless for some > reason it can't, like if there's a compiler-generated need to take the > address of the rvalue reference, Bingo. This is exactly what happened---compiler-generated code was going through build_unary_op, and triggering this error when it was okay to take the address of the result. > and we're going through build_unary_op > instead of build_address. I didn't think of that. build_address doesn't do the ADDR_EXPR/INDIRECT_REF simplification, which some of the current callers of build_unary_op(ADDR_EXPR...) might rely on. So, I can try to change the compiler-generated calls to build_unary_op(ADDR_EXPR...) into build_address, and move the address-of-rvalue check into build_unary_op, if you'd still prefer that implementation. - Doug