From: Ziemowit Laski <zlaski@apple.com>
To: Joe Buck <Joe.Buck@synopsys.com>
Cc: gcc mailing list <gcc@gcc.gnu.org>, Michael Matz <matz@suse.de>,
Matt Austern <austern@apple.com>,
Andrew Pinski <pinskia@physics.uc.edu>,
Mike Stump <mrs@apple.com>
Subject: Re: generalized lvalues
Date: Sat, 20 Nov 2004 01:51:00 -0000 [thread overview]
Message-ID: <9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com> (raw)
In-Reply-To: <20041119170011.A30410@synopsys.com>
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
next prev parent reply other threads:[~2004-11-20 1:30 UTC|newest]
Thread overview: 116+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-18 3:50 Matt Austern
2004-11-18 3:52 ` Andrew Pinski
2004-11-18 4:01 ` Andrew Pinski
2004-11-18 4:18 ` Daniel Berlin
2004-11-18 4:21 ` Andrew Pinski
2004-11-18 4:27 ` Matt Austern
2004-11-18 7:15 ` Joe Buck
2004-11-18 7:37 ` Matt Austern
2004-11-18 13:17 ` Giovanni Bajo
2004-11-18 17:57 ` Joe Buck
2004-11-18 18:28 ` Mike Stump
2004-11-18 18:44 ` Joe Buck
2004-11-19 1:39 ` Mike Stump
2004-11-19 4:52 ` Matt Austern
2004-11-19 22:24 ` Michael Matz
2004-11-19 22:30 ` Robert McNulty Junior
2004-11-20 1:00 ` Ziemowit Laski
2004-11-20 1:20 ` Joe Buck
2004-11-20 1:51 ` Ziemowit Laski [this message]
2004-11-20 5:04 ` Joe Buck
2004-11-20 5:17 ` Ziemowit Laski
2004-11-22 20:54 ` generalized lvalues -- patch outline Ziemowit Laski
2004-11-22 21:01 ` Andrew Pinski
2004-11-22 21:11 ` Ziemowit Laski
2004-11-22 21:39 ` Matt Austern
2004-11-22 22:11 ` Joe Buck
2004-11-22 22:12 ` Matt Austern
2004-11-23 0:06 ` Gabriel Dos Reis
2004-11-23 0:04 ` Gabriel Dos Reis
2004-11-23 0:27 ` Mike Stump
2004-11-24 20:40 ` Kai Henningsen
2004-11-23 0:11 ` Mark Mitchell
2004-11-23 1:19 ` Matt Austern
2004-11-23 1:26 ` Mark Mitchell
2004-11-23 1:32 ` Dale Johannesen
2004-11-23 1:42 ` Mark Mitchell
2004-11-23 1:45 ` Andrew Pinski
2004-11-23 1:55 ` Dale Johannesen
2004-11-23 1:56 ` Andrew Pinski
2004-11-23 2:12 ` Dale Johannesen
2004-11-23 2:10 ` Marcus G. Daniels
2004-11-23 9:43 ` Eric Botcazou
2004-11-23 18:27 ` Aaron W. LaFramboise
2004-11-22 21:23 ` Nathan Sidwell
2004-11-22 22:33 ` Ziemowit Laski
2004-11-23 0:09 ` Gabriel Dos Reis
2004-11-23 9:54 ` Nathan Sidwell
2004-11-23 13:35 ` Michael Matz
2004-11-23 14:56 ` Daniel Berlin
2004-11-23 15:02 ` Michael Matz
2004-11-23 15:15 ` Andrew Pinski
2004-11-23 15:47 ` Michael Matz
2004-11-23 15:56 ` Gabriel Dos Reis
2004-11-23 15:50 ` Steve Naroff
2004-11-23 15:51 ` Gabriel Dos Reis
2004-11-23 16:50 ` Eric Botcazou
2004-11-23 17:01 ` Paul Koning
2004-11-23 17:16 ` Andreas Schwab
2004-11-23 18:03 ` Thomas Kunert
2004-11-23 18:30 ` Nathan Sidwell
2004-11-23 18:57 ` Thomas Kunert
2004-11-23 21:21 ` Paul Koning
2004-11-23 21:52 ` Thomas Kunert
2004-11-23 15:51 ` Gabriel Dos Reis
2004-11-23 16:12 ` Michael Matz
2004-11-23 16:31 ` Richard Guenther
2004-11-23 16:44 ` Andreas Schwab
2004-11-23 20:16 ` Gabriel Dos Reis
2004-11-23 15:01 ` Nathan Sidwell
2004-11-23 15:09 ` Michael Matz
2004-11-23 19:11 ` Matt Austern
2004-11-23 21:10 ` Eric Botcazou
2004-11-23 21:34 ` Ziemowit Laski
2004-11-23 22:09 ` Joseph S. Myers
2004-11-23 22:23 ` Eric Botcazou
2004-11-23 22:27 ` Joseph S. Myers
2004-11-24 0:05 ` Eric Botcazou
2004-11-24 0:07 ` Steven Bosscher
2004-11-24 0:32 ` Joseph S. Myers
2004-11-25 8:41 ` Ian Lance Taylor
2004-11-25 20:41 ` Gabriel Dos Reis
2004-11-25 21:54 ` Matt Austern
2004-11-25 23:27 ` Gabriel Dos Reis
2004-11-29 18:06 ` Joe Buck
2004-11-29 18:57 ` Matt Austern
2004-11-23 23:27 ` Gabriel Dos Reis
2004-11-23 22:24 ` Nathan Sidwell
2004-11-23 0:07 ` Gabriel Dos Reis
2004-11-24 20:43 ` Kai Henningsen
2004-11-24 23:09 ` Gabriel Dos Reis
2004-11-24 23:17 ` Zack Weinberg
2004-11-22 21:31 ` Richard Henderson
2004-11-23 0:11 ` Gabriel Dos Reis
2004-11-23 0:03 ` Jonathan Lennox
2004-11-20 1:40 ` generalized lvalues Joseph S. Myers
2004-11-18 19:11 ` Alex Rosenberg
2004-11-18 4:24 ` Matt Austern
2004-11-18 5:33 ` Dale Johannesen
2004-11-18 17:14 ` Fariborz Jahanian
2004-11-18 18:23 ` Joe Buck
2004-11-19 0:20 ` Ziemowit Laski
2004-11-19 0:40 ` Steven Bosscher
2004-11-19 1:20 ` Joe Buck
2004-11-19 2:00 ` Ziemowit Laski
2004-11-18 23:36 ` Ziemowit Laski
2004-11-18 23:37 ` Matt Austern
2004-11-18 23:49 ` Zack Weinberg
2004-11-19 1:38 ` Ziemowit Laski
2004-11-19 2:52 ` Zack Weinberg
2004-11-19 3:56 ` Ziemowit Laski
2004-11-19 4:22 ` Zack Weinberg
2004-11-19 13:10 ` Nathan Sidwell
2004-11-19 21:58 ` Ziemowit Laski
2004-11-18 23:44 ` Andrew Pinski
2004-11-18 23:45 ` Joe Buck
2004-11-25 4:42 ` Aaron W. LaFramboise
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9E6AD708-3A93-11D9-9070-000D9330C50E@apple.com \
--to=zlaski@apple.com \
--cc=Joe.Buck@synopsys.com \
--cc=austern@apple.com \
--cc=gcc@gcc.gnu.org \
--cc=matz@suse.de \
--cc=mrs@apple.com \
--cc=pinskia@physics.uc.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).