From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20455 invoked by alias); 20 Nov 2004 01:00:20 -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 20316 invoked from network); 20 Nov 2004 01:00:13 -0000 Received: from unknown (HELO kiruna.synopsys.com) (198.182.44.80) by sourceware.org with SMTP; 20 Nov 2004 01:00:13 -0000 Received: from mother.synopsys.com (mother.synopsys.com [146.225.100.171]) by kiruna.synopsys.com (Postfix) with ESMTP id 6F473F54B; Fri, 19 Nov 2004 16:59:51 -0800 (PST) Received: from piper.synopsys.com (localhost [127.0.0.1]) by mother.synopsys.com (8.9.1/8.9.1) with ESMTP id RAA15105; Fri, 19 Nov 2004 17:00:12 -0800 (PST) Received: (from jbuck@localhost) by piper.synopsys.com (8.11.6/8.11.6) id iAK10Bn31025; Fri, 19 Nov 2004 17:00:11 -0800 X-Authentication-Warning: piper.synopsys.com: jbuck set sender to Joe.Buck@synopsys.com using -f Date: Sat, 20 Nov 2004 01:20:00 -0000 From: Joe Buck To: Ziemowit Laski Cc: Michael Matz , gcc mailing list , Matt Austern , Mike Stump , Andrew Pinski Subject: Re: generalized lvalues Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from zlaski@apple.com on Fri, Nov 19, 2004 at 04:40:35PM -0800 X-SW-Source: 2004-11/txt/msg00709.txt.bz2 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.