From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12222 invoked by alias); 20 Nov 2004 01:30:50 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 12188 invoked from network); 20 Nov 2004 01:30:43 -0000 Received: from unknown (HELO mail-out3.apple.com) (17.254.13.22) by sourceware.org with SMTP; 20 Nov 2004 01:30:43 -0000 Received: from mailgate1.apple.com (a17-128-100-225.apple.com [17.128.100.225]) by mail-out3.apple.com (8.12.11/8.12.11) with ESMTP id iAK1apLp001301 for ; Fri, 19 Nov 2004 17:36:52 -0800 (PST) Received: from relay2.apple.com (relay2.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.3.14) with ESMTP id ; Fri, 19 Nov 2004 17:31:23 -0800 Received: from [17.201.24.57] (polskifiat.apple.com [17.201.24.57]) by relay2.apple.com (8.12.11/8.12.11) with ESMTP id iAK1UPpT022963; Fri, 19 Nov 2004 17:30:25 -0800 (PST) In-Reply-To: <20041119170011.A30410@synopsys.com> References: <78169FF3-3916-11D9-AEB4-000A95D692F4@physics.uc.edu> <4D2CF60C-3919-11D9-8BD2-000A95BCF344@apple.com> <20041117212847.A26376@synopsys.com> <6F5FC748-7BBD-44B9-8DDC-246949F16102@apple.com> <20041118102741.A8347@synopsys.com> <77E8D36A-C0C2-4B03-964C-BEE0FE7BBBC3@apple.com> <98C86CD4-39E2-11D9-B2D5-000A95BCF344@apple.com> <20041119170011.A30410@synopsys.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com> Content-Transfer-Encoding: 7bit Cc: gcc mailing list , Michael Matz , Matt Austern , Andrew Pinski , Mike Stump From: Ziemowit Laski Subject: Re: generalized lvalues Date: Sat, 20 Nov 2004 01:51:00 -0000 To: Joe Buck X-SW-Source: 2004-11/txt/msg00712.txt.bz2 On 19 Nov 2004, at 17.00, Joe Buck wrote: > On Fri, Nov 19, 2004 at 04:40:35PM -0800, Ziemowit Laski wrote: >> As I've alluded to in an earlier e-mail, bringing back the entire >> cast-as-lvalue >> functionality is probably not necessary (and yes, it can interact >> rather badly >> with C and C++, as I have finally been convinced). However, I did >> make >> a >> suggestion that we could create a special flag (e.g., >> '-fassign-to-cast' or >> some such) that would allow an assignment (including ++ and --) to a >> cast. > > The cast would have to be treated as a non-lvalue for the purposes of > C++ overloading. For cases where the cast is dereferenced, there are > issues with aliasing; -fno-strict-alias might have to be used to keep > the compiler from generating bad code (this doesn't affect the pointer > increment case, only if a value is written through a cast). > > And then there's the problem of representing cast-as-lvalue in GIMPLE; > I'm not competent to advise you there. The case where > > ((type*)voidp)++; > > is used because you want to add > sizeof(type) to a void pointer could just be turned into > > type* tmp = voidp; > ++tmp; > voidp = tmp; > > by the front end, but I have no clue about how to handle the general > case, partly because I'm not even sure what the semantics are. What I was hoping for is that we can turn (cast)expr = ... *(cast)expr)++ into *((cast *)&expr) = ... *((cast *)&expr)++ when -fassign-to-cast is specified. This transformation can serve as a definition for what -fassign-to-cast does, and also should help with gimplification. In the transformation, the '&' and '*' operators would always denote ADDR_EXPR and INDIRECT_REF, so that any C++ redefinition thereof would not affect things. Of course, the problems we previously discussed will still persist if one subsequently uses the transformed result for something else, e.g., foo = (cast)bar = baz; overloaded_cxx_func((cast)foo = init); but here I think it may be fine to make the buyer beware (with an appropriate discussion in the manual under -fassign-to-cast) and/or issue a suitable warning under such circumstances. --Zem