From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5122 invoked by alias); 20 Nov 2004 01:20:04 -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 5071 invoked from network); 20 Nov 2004 01:19:55 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9) by sourceware.org with SMTP; 20 Nov 2004 01:19:55 -0000 Received: (qmail 29844 invoked from network); 20 Nov 2004 01:19:55 -0000 Received: from localhost (HELO digraph.polyomino.org.uk) (joseph@127.0.0.1) by mail.codesourcery.com with DES-CBC3-SHA encrypted SMTP; 20 Nov 2004 01:19:55 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.42) id 1CVJvG-0008Jy-Lj; Sat, 20 Nov 2004 01:20:18 +0000 Date: Sat, 20 Nov 2004 01:40:00 -0000 From: "Joseph S. Myers" X-X-Sender: jsm28@digraph.polyomino.org.uk To: Ziemowit Laski cc: Michael Matz , gcc mailing list , Matt Austern , Mike Stump , Joe Buck , Andrew Pinski Subject: Re: generalized lvalues In-Reply-To: Message-ID: References: <8AD5AEEF-3914-11D9-8BD2-000A95BCF344@apple.com> <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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2004-11/txt/msg00711.txt.bz2 On Fri, 19 Nov 2004, 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. > > Would such an approach be acceptable? The removal of cast-as-lvalue got rid of a lot of crufty code. Bringing it back under a conditional is not a good idea. For your ObjC uses, you don't want to allow assignments to casts in general - only to some ObjC-specific constructs, which might or might not be syntactically casts to ObjC-specific types. I'd suggest detecting whatever construct (whether or not expressed as a cast in the syntax) and representing it as an ObjC-specific tree code, which acts as an lvalue and has whatever other magic semantics are required and is lowered in gimplification - not as NOP_EXPR/CONVERT_EXPR. The construct in question should only be able to occur in ObjC and ObjC++ code, not plain C or C++. -- Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/ jsm@polyomino.org.uk (personal mail) joseph@codesourcery.com (CodeSourcery mail) jsm28@gcc.gnu.org (Bugzilla assignments and CCs)