From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20604 invoked by alias); 12 Jun 2011 11:03:19 -0000 Received: (qmail 20588 invoked by uid 22791); 12 Jun 2011 11:03:18 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-ww0-f51.google.com (HELO mail-ww0-f51.google.com) (74.125.82.51) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 12 Jun 2011 11:03:04 +0000 Received: by wwf26 with SMTP id 26so3618370wwf.8 for ; Sun, 12 Jun 2011 04:03:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.227.32.84 with SMTP id b20mr3950438wbd.105.1307876583263; Sun, 12 Jun 2011 04:03:03 -0700 (PDT) Received: by 10.227.28.69 with HTTP; Sun, 12 Jun 2011 04:03:03 -0700 (PDT) In-Reply-To: References: <4DEDB98F.6010508@redhat.com> <4DEE2DCF.7020905@redhat.com> <4DEE3484.8030101@redhat.com> <4DF11FBC.3010304@redhat.com> <4DF223D4.3080700@redhat.com> <4DF22656.9050700@redhat.com> <4DF3C98B.6070006@redhat.com> Date: Sun, 12 Jun 2011 13:22:00 -0000 Message-ID: Subject: Re: Is VIEW_CONVERT_EXPR an lvalue? (was Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))) From: Richard Guenther To: Jason Merrill Cc: Richard Guenther , gcc-patches List , GCC Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2011-06/txt/msg00936.txt.bz2 On Sun, Jun 12, 2011 at 12:59 PM, Richard Guenther wrote: > On Sat, Jun 11, 2011 at 10:01 PM, Jason Merrill wrote: >> On 06/10/2011 10:20 AM, Richard Guenther wrote: >>> >>> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example >>> would turn the above to (volatile int) a[1]). >> >> The gimplifier seems to consider it an lvalue: gimplify_expr uses >> gimplify_compound_lval for it, and gimplify_addr_expr handles taking its >> address. =A0And get_inner_reference handles it. =A0So I think fold shoul= d be >> changed, and we should clarify that VIEW_CONVERT_EXPR is an lvalue. >> >> If not, we need a new tree code for treating an lvalue as an lvalue of a >> different type without having to take its address; that's what I thought >> VIEW_CONVERT_EXPR was for. Btw, see tree.def which says /* Represents viewing something of one type as being of a second type. This corresponds to an "Unchecked Conversion" in Ada and roughly to the idiom *(type2 *)&X in C. The only operand is the value to be viewed as being of another type. It is undefined if the type of the input and of the expression have different sizes. This code may also be used within the LHS of a MODIFY_EXPR, in which case no actual data motion may occur. TREE_ADDRESSABLE will be set in this case and GCC must abort if it could not do the operation without generating insns. */ DEFTREECODE (VIEW_CONVERT_EXPR, "view_convert_expr", tcc_reference, 1) > The please provide a specification on what a VIEW_CONVERT_EXPR does > to type-based alias analysis. =A0We are trying to avoid that by the rvalu= e rule. > Also you can always avoid VIEW_CONVERT_EXPRs for lvalues by simply > moving the conversion to the rvalue side. > > Yes, we do handle lvalue VIEW_CONVERT_EXPRs, but that is for Ada > which uses it for aggregates. =A0I don't want us to add more lvalue > VIEW_CONVERT_EXPR > cases, especially not for register types. > > Richard. > >> Jason >> >