From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-294238-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 5133 invoked by alias); 11 Jun 2011 17:45:43 -0000
Received: (qmail 5118 invoked by uid 22791); 11 Jun 2011 17:45:42 -0000
X-SWARE-Spam-Status: No, hits=-1.8 required=5.0	tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RFC_ABUSE_POST,T_RP_MATCHES_RCVD
X-Spam-Check-By: sourceware.org
Received: from qmta15.emeryville.ca.mail.comcast.net (HELO qmta15.emeryville.ca.mail.comcast.net) (76.96.27.228)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Jun 2011 17:45:27 +0000
Received: from omta06.emeryville.ca.mail.comcast.net ([76.96.30.51])	by qmta15.emeryville.ca.mail.comcast.net with comcast	id uhii1g00216AWCUAFhlQM6; Sat, 11 Jun 2011 17:45:24 +0000
Received: from up.mrs.kithrup.com ([24.4.193.8])	by omta06.emeryville.ca.mail.comcast.net with comcast	id uhlP1g0090BKwT48ShlQBX; Sat, 11 Jun 2011 17:45:25 +0000
Subject: Re: RFA (fold): PATCH for c++/49290 (folding *(T*)(ar+10))
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Mike Stump <mikestump@comcast.net>
In-Reply-To: <alpine.LNX.2.00.1106101619070.810@zhemvz.fhfr.qr>
Date: Sat, 11 Jun 2011 18:24:00 -0000
Cc: Jason Merrill <jason@redhat.com>, Richard Guenther <richard.guenther@gmail.com>, gcc-patches List <gcc-patches@gcc.gnu.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <37B61697-B4A5-49B6-87C4-AD361A86F752@comcast.net>
References: <4DEDB98F.6010508@redhat.com> <BANLkTimU_JPKgaqvhtb+m7fbDyTL340YJQ@mail.gmail.com> <4DEE2DCF.7020905@redhat.com> <BANLkTi=FX60RhEj2QF=t9MvkUCHR=D1m1A@mail.gmail.com> <4DEE3484.8030101@redhat.com> <4DF11FBC.3010304@redhat.com> <alpine.LNX.2.00.1106101029320.810@zhemvz.fhfr.qr> <4DF223D4.3080700@redhat.com> <alpine.LNX.2.00.1106101602530.810@zhemvz.fhfr.qr> <4DF22656.9050700@redhat.com> <alpine.LNX.2.00.1106101619070.810@zhemvz.fhfr.qr>
To: Richard Guenther <rguenther@suse.de>
X-IsSubscribed: yes
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2011-06/txt/msg00923.txt.bz2

On Jun 10, 2011, at 7:20 AM, Richard Guenther wrote:
> On Fri, 10 Jun 2011, Jason Merrill wrote:
>=20
>> On 06/10/2011 10:03 AM, Richard Guenther wrote:
>>>>> *((volatile int *)&a[0] + 1)
>>>>=20
>>>> It would be correct to fold it to
>>>>=20
>>>> VIEW_CONVERT_EXPR<volatile int,a[1]>
>>>=20
>>> No, it wouldn't be correct.  It isn't correct to fold it to an array-ref
>>> that isn't volatile.
>>=20
>> Hmm?  The C expression produces a volatile int lvalue referring to the s=
econd
>> element of a, as does the VIEW_CONVERT_EXPR.  They seem equivalent to me.
>=20
> no, a VIEW_CONVERT_EXPR is generally not an lvalue (fold for example
> would turn the above to (volatile int) a[1]).

Curious.  We have built up a built-in infrastructure that allows for lvalue=
 register references.  I noticed that for vector types, vectors with differ=
ent type names but the same in every other respect come out different, and =
a VIEW_CONVERT_EXPR is placed on it to get the types to match.  Presently I=
'm treating VIEW_CONVERT_EXPR as an lvalue.  For me not to, I'd need either=
 for the same type to be used, or, for another conversion node to be used t=
hat can preserve the lvalueness of registers.

Now, if people want to know why, lvalue for registers, it is to support in/=
out and output only parameters to built-ins.

Thoughts?