Re: generalized lvalues

[Ziemowit Laski <zlaski at apple dot 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