generalized lvalues

generalized lvalues

[Matt Austern]

Could somebody remind me, please, of the reasons we removed generalized 
lvalues?  I know there were several reasons, but I'm not sure if I've 
ever seen a complete list.  Here are the reasons I can reconstruct from 
memory:
  1. It broke valid C++ programs.  If we overload a function on 
constness, like foo(int&) and foo(const int&), then invoking it as 
foo((int) x) is required to call the const version.  Generalized 
lvalues made us choose the latter.
  2. It was underspecified. There were cases, again especially in C++ in 
the presence of operator overloading, where nobody was quite sure 
either what it did or what it was supposed to do.
  3. I have the vague sense that it caused back end bugs, but I can't 
find them offhand.

Anything else?  (Incidentally, I think all of these apply to 
cast-as-lvalue.  I haven't heard of any problems caused by 
conditional-as-lvalue or comma-expression-as-lvalue.)

The reason I'm asking: I think some people are going to find the 
removal a nasty surprise.  Yes, it was deprecated in 3.3.x and 3.4.x, 
but not everyone upgrades to the latest release of older branches. I 
imagine some people won't have noticed the discussion about removal 
until they upgrade to 4.0 and see that it's gone.  At that point we'll 
have three choices: convince them that removing it made the compiler 
better, or reconsider and put it back, or refuse to put it back, don't 
tell anyone why it's gone, and live with unhappy users who think we're 
stupid and capricious.  If we want to go with one of the first two 
options, it'll help to have a collection of reasons.

			--Matt

Re: generalized lvalues

[Andrew Pinski]

On Nov 17, 2004, at 10:47 PM, Matt Austern wrote:

>  3. I have the vague sense that it caused back end bugs, but I can't 
> find them offhand.

There was no way to represent them in gimple.

-- Pinski

Re: generalized lvalues

[Andrew Pinski]

On Nov 17, 2004, at 10:47 PM, Matt Austern wrote:

>  1. It broke valid C++ programs.  If we overload a function on 
> constness, like foo(int&) and foo(const int&), then invoking it as 
> foo((int) x) is required to call the const version.  Generalized 
> lvalues made us choose the latter.

If it broke it please file a bug and don't complain that we broke it.

-- Pinski

Re: generalized lvalues

[Daniel Berlin]

On Wed, 17 Nov 2004, Andrew Pinski wrote:

>
> On Nov 17, 2004, at 10:47 PM, Matt Austern wrote:
>
>>  1. It broke valid C++ programs.  If we overload a function on constness, 
>> like foo(int&) and foo(const int&), then invoking it as foo((int) x) is 
>> required to call the const version.  Generalized lvalues made us choose 
>> the latter.
>
> If it broke it please file a bug and don't complain that we broke it.

I believe you interpreted what he said backwards :)
I believe he means that the generalized lvalues made us get some valid C++ 
programs choose the wrong fnuction to call, and that removing the 
extension fixed that :)

Re: generalized lvalues

[Andrew Pinski]

On Nov 17, 2004, at 10:50 PM, Andrew Pinski wrote:

>
> On Nov 17, 2004, at 10:47 PM, Matt Austern wrote:
>
>>  1. It broke valid C++ programs.  If we overload a function on 
>> constness, like foo(int&) and foo(const int&), then invoking it as 
>> foo((int) x) is required to call the const version.  Generalized 
>> lvalues made us choose the latter.
>
> If it broke it please file a bug and don't complain that we broke it.

Woops I read it wrong but note the C++ front-end removed this extension
in 3.4.0 and not just for 4.0.0.

Also removing deprecated stuff after a year is more enough time for
people to change their code.


Also the proposal to deprecate this in C++ was back in May of 2003
which is more than enough time to object to the original proposal.

In fact you commented on the original proposal:
http://gcc.gnu.org/ml/gcc/2003-05/msg00933.html
And you concluded the same thing to remove it:
---- quote --------
I agree, for what it's worth, that this extension should go.  It was
poorly thought out, and we never specified how it was supposed to
interact with other language features.  (We've seen two different
problems with it in the Apple code base.)  Doing language extension
correctly takes a lot of work.
----- end quote ------


-- Pinski

Re: generalized lvalues

[Matt Austern]

On Nov 17, 2004, at 8:01 PM, Andrew Pinski wrote:

>
> On Nov 17, 2004, at 10:50 PM, Andrew Pinski wrote:
>
>>
>> On Nov 17, 2004, at 10:47 PM, Matt Austern wrote:
>>
>>>  1. It broke valid C++ programs.  If we overload a function on 
>>> constness, like foo(int&) and foo(const int&), then invoking it as 
>>> foo((int) x) is required to call the const version.  Generalized 
>>> lvalues made us choose the latter.
>>
>> If it broke it please file a bug and don't complain that we broke it.
>
> Woops I read it wrong but note the C++ front-end removed this extension
> in 3.4.0 and not just for 4.0.0.
>
> Also removing deprecated stuff after a year is more enough time for
> people to change their code.
>
>
> Also the proposal to deprecate this in C++ was back in May of 2003
> which is more than enough time to object to the original proposal.
>
> In fact you commented on the original proposal:
> http://gcc.gnu.org/ml/gcc/2003-05/msg00933.html
> And you concluded the same thing to remove it:

Yep, and I'm still not arguing against removing it.  I'm just asking 
for help in collecting a list of the reasons why we chose to get rid of 
it.  I don't think this discussion will go away, and having that list 
will be helpful.  I think a number of us will be asked: (a) why did 
this extension disappear; and (b) how should I change my code to cope 
with the disappearance.  I'd like to be prepared with answers to those 
questions.

			--Matt

Re: generalized lvalues

[Joe Buck]

On Wed, Nov 17, 2004 at 08:21:21PM -0800, Matt Austern wrote:
> Yep, and I'm still not arguing against removing it.  I'm just asking 
> for help in collecting a list of the reasons why we chose to get rid of 
> it.  I don't think this discussion will go away, and having that list 
> will be helpful.  I think a number of us will be asked: (a) why did 
> this extension disappear; and (b) how should I change my code to cope 
> with the disappearance.  I'd like to be prepared with answers to those 
> questions.

I doubt if you will get the flood of questions you anticipate, because
few people even knew that the extension was there.  It is possible that
someone has a production program that is not valid C++ that will now
break, but if this happens we just tell them how to fix the program.

Re: generalized lvalues

[Matt Austern]

On Nov 17, 2004, at 9:28 PM, Joe Buck wrote:

> On Wed, Nov 17, 2004 at 08:21:21PM -0800, Matt Austern wrote:
>> Yep, and I'm still not arguing against removing it.  I'm just asking
>> for help in collecting a list of the reasons why we chose to get rid 
>> of
>> it.  I don't think this discussion will go away, and having that list
>> will be helpful.  I think a number of us will be asked: (a) why did
>> this extension disappear; and (b) how should I change my code to cope
>> with the disappearance.  I'd like to be prepared with answers to those
>> questions.
>
> I doubt if you will get the flood of questions you anticipate, because
> few people even knew that the extension was there.  It is possible that
> someone has a production program that is not valid C++ that will now
> break, but if this happens we just tell them how to fix the program.

I hope you're right.  I take the pessimistic view that there are lots of
programmers who have no idea what the language definition is for
the language they're using, but just throw code at the compiler until
the compiler produces an executable that seems to work.  So I think
there may be some people who are using the cast-as-lvalue
extension even if they don't know what a cast or an lvalue is.

			--matt

Re: generalized lvalues

[Giovanni Bajo]

Matt Austern <austern@apple.com> wrote:

> I take the pessimistic view that there are lots
> of programmers who have no idea what the language definition is for
> the language they're using, but just throw code at the compiler until
> the compiler produces an executable that seems to work.

That is surely true.

> So I think
> there may be some people who are using the cast-as-lvalue
> extension even if they don't know what a cast or an lvalue is.

Sure. Lately, I have been asked help to upgrade an existing C++ codebase from
2.95 to 3.4. I addressed the guys (which have no advanced C++ knowledge at all,
let alone standard terms understanding) to changes.html for that release, and
that allowed them to fix all the problems *but* this line:

int x;
[....]
(short)x = a;

What they actually wanted to do is "x = (short)a", but they could not come up
with this trivial fix by themselves. Notice that changes.html mention this
issue but does not suggest how to fix this bug (not even in such a trivial
case). The other half of the problem is that our error message is:

     lvalue.cc:5: error: non-lvalue in assignment

which requires knowledge of what a lvalue is. And whatever we may think, they
do not teach that in C++ 101.

If you want to pursue a small task to ease the removal of this feature, I
suggest you to prepare a patch against the C/C++ frontend to simplify the text
of the diagnostic, and one against changes.html to simplify the wording (maybe
explaining in 3 words what a lvalue is) and suggesting some possible solution.

Giovanni Bajo

Re: generalized lvalues

[Joe Buck]

On Wed, Nov 17, 2004 at 09:33:42PM -0800, Matt Austern wrote:
> > I doubt if you will get the flood of questions you anticipate, because
> > few people even knew that the extension was there.  It is possible that
> > someone has a production program that is not valid C++ that will now
> > break, but if this happens we just tell them how to fix the program.
> 
> I hope you're right.  I take the pessimistic view that there are lots of
> programmers who have no idea what the language definition is for
> the language they're using, but just throw code at the compiler until
> the compiler produces an executable that seems to work.

It is true that there is a lot of this.  However, in this particular case,
assigning to a cast and expecting it to work isn't something that people
just stumble on to accidentally.

Re: generalized lvalues

[Mike Stump]

On Nov 17, 2004, at 9:28 PM, Joe Buck wrote:
> On Wed, Nov 17, 2004 at 08:21:21PM -0800, Matt Austern wrote:
>
>> Yep, and I'm still not arguing against removing it.  I'm just asking
>> for help in collecting a list of the reasons why we chose to get rid 
>> of
>> it.  I don't think this discussion will go away, and having that list
>> will be helpful.  I think a number of us will be asked: (a) why did
>> this extension disappear; and (b) how should I change my code to cope
>> with the disappearance.  I'd like to be prepared with answers to those
>> questions.
>>
>
> I doubt if you will get the flood of questions you anticipate, because
> few people even knew that the extension was there.  It is possible that
> someone has a production program that is not valid C++ that will now
> break, but if this happens we just tell them how to fix the program.

Just a random data point, 58 out of 1252 (4.6%) projects failed to 
build because of it.

Re: generalized lvalues

[Joe Buck]

On Thu, Nov 18, 2004 at 10:19:18AM -0800, Mike Stump wrote:
> > I doubt if you will get the flood of questions you anticipate, because
> > few people even knew that the extension was there.  It is possible that
> > someone has a production program that is not valid C++ that will now
> > break, but if this happens we just tell them how to fix the program.
> 
> Just a random data point, 58 out of 1252 (4.6%) projects failed to 
> build because of it.

Really?  Can you show some of the example errors?  And are they really
due to this extension specifically, or to other changes in gcc 3.4.x?

Re: generalized lvalues

[Mike Stump]

On Nov 18, 2004, at 10:27 AM, Joe Buck wrote:
> Really?

AFAIK.

> Can you show some of the example errors?

Sounds boring and tedious, I don't see any benefit to doing that work.  
I've accepted the extension is gone and just plan on informing users it 
is gone.

If details about that would help bring it back and someone around here 
really wants to bring it back, then, they can furnish those details...  
:-)

> And are they really due to this extension specifically?

AFAIK.

The side world build people do the builds with newer compilers on the 
world, and then attempt to categorize the failures and the causes of 
those failures.  We get ICEs out of it, tightened up compilers, codegen 
bugs (link failures, assembly failures) and so on.  Usually the first 
in the series of bugs is routed through one of the compiler people to 
discern what category the propblem is in, and then farmed out as 
appropriate.  If two independent things cause otherwise identical error 
messages, then, it is possible there could be multiple causes.  In any 
event, what we do know, is that these things used to compile, and now 
don't.

Also, this is a lower bound number, as there can be other reasons why 
the project didn't get far enough in the compilation to find such a 
problem.

Re: generalized lvalues

[Matt Austern]

On Nov 18, 2004, at 5:26 PM, Mike Stump wrote:

> On Nov 18, 2004, at 10:27 AM, Joe Buck wrote:
>> Really?
>
> AFAIK.
>
>> Can you show some of the example errors?
>
> Sounds boring and tedious, I don't see any benefit to doing that work. 
>  I've accepted the extension is gone and just plan on informing users 
> it is gone.

But I'll give two examples (details changed partly to protect the 
guilty and partly because I'm doing this by memory):
(1) #define foo(x) *(a, b, x)
(2) ((long*) p)++

Again, I'm not arguing that this extension should come back.  I'm 
unhappy about the whole situation, because (as Joe pointed out) we had 
a choice between removing an extension without the usual amount of 
notice and the usual number of releases where it's deprecated, or else 
accepting a serious bug in our C++ front end and not fixing it.  At the 
time I thought the former choice was less bad, and I think that's still 
probably true.  But right now I'm mostly interested in collecting 
information.  I'd like to make sure I understand all of the 
consequences of our decision.

I'm most interested in your comment, Andrew, that cast-as-lvalue was 
impossible to accommodate in GIMPLE.  Can you expand on that?

			--Matt

Re: generalized lvalues

[Michael Matz]

Hi,

On Thu, 18 Nov 2004, Matt Austern wrote:

> But I'll give two examples (details changed partly to protect the guilty and
> partly because I'm doing this by memory):
> (1) #define foo(x) *(a, b, x)
> (2) ((long*) p)++

Actually, from my experience looking at assorted packages which are tried
to be build with 4.0, the latter use is most common.  I.e. casting a
pointer to some type to implicitely specify how much it is incremented.  
Some software is very much known for using such constructs (wine, rpm,
elfutils, dietlibs, many others) .  I even tend to say, that such usage is
well defined (within certain limits), although I admit that it's not ISO
C99.

<rant>
All the whining about how unspecified this is, and how the writer of the
code deserve to be bitten, is just language lawyer masturbation (which I
also very much enjoy when closing bugreports about this or that compiler
bug with INVALID), but it doesn't change the fact, that there are quite
some packages out there actually using such extensions.  This 
cast-as-lvalue extension removal is one of the bigger items which result 
in much work for package maintainers (not so much for C++, as there anyway 
this extension wasn't used much).
</rant>

So, if anyone wants to bring it back, with defined semantics of course
(like for instance memory accessed through a casted pointer is well
defined (not outside the memory for the object accessed), and only for C)  
I'm all ears.


Ciao,
Michael.

Re: generalized lvalues

[Robert McNulty Junior]

Michael Matz wrote:

>Hi,
>
>On Thu, 18 Nov 2004, Matt Austern wrote:
>
>  
>
>>But I'll give two examples (details changed partly to protect the guilty and
>>partly because I'm doing this by memory):
>>(1) #define foo(x) *(a, b, x)
>>(2) ((long*) p)++
>>    
>>
>
>Actually, from my experience looking at assorted packages which are tried
>to be build with 4.0, the latter use is most common.  I.e. casting a
>pointer to some type to implicitely specify how much it is incremented.  
>Some software is very much known for using such constructs (wine, rpm,
>elfutils, dietlibs, many others) .  I even tend to say, that such usage is
>well defined (within certain limits), although I admit that it's not ISO
>C99.
>
><rant>
>All the whining about how unspecified this is, and how the writer of the
>code deserve to be bitten, is just language lawyer masturbation (which I
>also very much enjoy when closing bugreports about this or that compiler
>bug with INVALID), but it doesn't change the fact, that there are quite
>some packages out there actually using such extensions.  This 
>cast-as-lvalue extension removal is one of the bigger items which result 
>in much work for package maintainers (not so much for C++, as there anyway 
>this extension wasn't used much).
></rant>
>
>So, if anyone wants to bring it back, with defined semantics of course
>(like for instance memory accessed through a casted pointer is well
>defined (not outside the memory for the object accessed), and only for C)  
>I'm all ears.
>
>
>Ciao,
>Michael.
>
>  
>
Micheal, GCC 4.0 looks cool. I have the latest CVS. 
http://www.geocities.com/bobbymcn2004 will take you to a site of music 
that was made with a program using GCC 4.0.
Under Cygwin.
All my latest music is there. This is my dream. You guys have done it. 
GCC has come a long way since  I started with you four years ago with 
GCC 3.0. I'm using Cygwin. One problem. The songs are encoded in Windows 
Media Encoder, so you need a player that plays wma files.
There's not that many. And yes, that's me playing the piano. Neat.
GCC 4.0, when its released will be appreciated by all.

Re: generalized lvalues

[Ziemowit Laski]

On 19 Nov 2004, at 13.50, Michael Matz wrote:

>> (1) #define foo(x) *(a, b, x)
>> (2) ((long*) p)++
>
> Actually, from my experience looking at assorted packages which are 
> tried
> to be build with 4.0, the latter use is most common.  I.e. casting a
> pointer to some type to implicitely specify how much it is incremented.
> Some software is very much known for using such constructs (wine, rpm,
> elfutils, dietlibs, many others) .  I even tend to say, that such 
> usage is
> well defined (within certain limits), although I admit that it's not 
> ISO
> C99.
>
> <rant>
> All the whining about how unspecified this is, and how the writer of 
> the
> code deserve to be bitten, is just language lawyer masturbation (which 
> I
> also very much enjoy when closing bugreports about this or that 
> compiler
> bug with INVALID), but it doesn't change the fact, that there are quite
> some packages out there actually using such extensions.  This
> cast-as-lvalue extension removal is one of the bigger items which 
> result
> in much work for package maintainers (not so much for C++, as there 
> anyway
> this extension wasn't used much).
> </rant>
>
> So, if anyone wants to bring it back, with defined semantics of course
> (like for instance memory accessed through a casted pointer is well
> defined (not outside the memory for the object accessed), and only for 
> C)
> I'm all ears.

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?

Thanks,

--Zem

Re: generalized lvalues

[Joe Buck]

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.

Re: generalized lvalues

[Ziemowit Laski]

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

Re: generalized lvalues

[Joe Buck]

On Fri, Nov 19, 2004 at 05:29:27PM -0800, Ziemowit Laski wrote:
> 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.

So, it appears that you want to turn (cast)expr into *((cast *)&expr).
You still have the issue with C++ overloading; since it is an lvalue,
if you have

void func(cast&);
void func(const cast&);

then

func((cast)expr) will call the wrong function, because with your rule,
func(cast&) gets called, while with the ISO C++ rule, func(const cast&)
gets called.

Now, you could get around this if you can specify a rule that explains
which casts get transformed and which don't.  This might be doable.

Also, if cast and typeof(expr) are not compatible types by the aliasing
rules of C, and the casted expression is written to, then the resulting
code may be mis-optimized unless the user also specifies
-fno-strict-alias.

I'd rather see Objective-C/C++ written in such a way that they don't
rely on writing to casts, though.

Re: generalized lvalues

[Ziemowit Laski]

On 19 Nov 2004, at 17.40, Joe Buck wrote:

> On Fri, Nov 19, 2004 at 05:29:27PM -0800, Ziemowit Laski wrote:
>> 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.
>
> So, it appears that you want to turn (cast)expr into *((cast *)&expr).
> You still have the issue with C++ overloading; since it is an lvalue,
> if you have
>
> void func(cast&);
> void func(const cast&);
>
> then
>
> func((cast)expr) will call the wrong function, because with your rule,
> func(cast&) gets called, while with the ISO C++ rule, func(const cast&)
> gets called.
>
> Now, you could get around this if you can specify a rule that explains
> which casts get transformed and which don't.

Only casts that are assigned to (or incremented or decremented) would 
be transformed,
and so only if _those_ casts are subsequently referenced do we run into 
the problems
you describe.  The 'func((cast)expr)' example you describe will be 
untouched.

To put it another way, I'm only concerned with cases where the compiler 
currently complains
about assigning to a non-lvalue, and the non-lvalue in question is a 
cast of an lvalue.

--Zem

generalized lvalues -- patch outline

[Ziemowit Laski]

On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:

> To put it another way, I'm only concerned with cases where the 
> compiler currently complains
> about assigning to a non-lvalue, and the non-lvalue in question is a 
> cast of an lvalue.

Indeed, I now appear to have a mainline mod for C and C++ which allows 
assignment to lvalue casts for pointer types.  What follows is a 
high-level synopsis of what I did; if there is interest, I can whip up 
a full-fledged patch, complete with docs.  Please let me know.

Thanks,

--Zem

------

The lvalue cast assignment/increment/decrement can be enabled with the 
-flvalue-cast-assign flag (which is off by default).

The active ingredient of the C patch is:

Index: gcc/c-typeck.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/c-typeck.c,v
retrieving revision 1.400
diff -u -3 -p -r1.400 c-typeck.c
--- gcc/c-typeck.c      20 Nov 2004 20:31:43 -0000      1.400
+++ gcc/c-typeck.c      22 Nov 2004 20:32:00 -0000
@@ -2724,6 +2724,16 @@ lvalue_or_else (tree ref, enum lvalue_us
  {
    int win = lvalue_p (ref);

+  /* If -flvalue-cast-assignment is specified, we shall allow 
assignments
+     (including increment/decrement) to casts of lvalues, as long as
+     both the lvalue and the cast are pointers.  */
+  if (!win && flag_lvalue_cast_assign
+      && TREE_CODE (ref) == NOP_EXPR
+      && (use == lv_assign || use == lv_increment || use == 
lv_decrement)
+      && TREE_CODE (TREE_TYPE (ref)) == POINTER_TYPE
+      && TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) == POINTER_TYPE)
+    win = lvalue_p (TREE_OPERAND (ref, 0));
+
    if (!win)
      {
        switch (use)

and will allow code as follows:

Index: gcc/testsuite/gcc.dg/lvalue-cast-1.c
===================================================================
RCS file: gcc/testsuite/gcc.dg/lvalue-cast-1.c
diff -N gcc/testsuite/gcc.dg/lvalue-cast-1.c
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ gcc/testsuite/gcc.dg/lvalue-cast-1.c        22 Nov 2004 20:32:50 
-0000
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-flvalue-cast-assign" } */
+
+int foo(void) {
+
+  char *p;
+  long l;
+  short s;
+
+  (long *)p = &l; /* ok */
+  ((long *)p)++;  /* ok */
+  (short)l = 2;   /* { dg-error "non-lvalue" } */
+  (long)s = 3;    /* { dg-error "non-lvalue" } */
+
+  return 0;
+}

Note that we're still erroring out on the non-pointer types, though 
that too can be changed.  FWIW, Microsoft's C compiler also allows the 
'(short)l = 2' (though not the '(long)s = 3').

The C++ side of things is very similar:

Index: gcc/cp/tree.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cp/tree.c,v
retrieving revision 1.419
diff -u -3 -p -r1.419 tree.c
--- gcc/cp/tree.c       12 Nov 2004 21:47:09 -0000      1.419
+++ gcc/cp/tree.c       22 Nov 2004 20:34:50 -0000
@@ -223,6 +223,17 @@ lvalue_or_else (tree ref, const char* st
  {
    if (!lvalue_p (ref))
      {
+      /* If -flvalue-cast-assignment is specified, we shall allow 
assignments
+        (including increment/decrement) to casts of lvalues, as long as
+        both the lvalue and the cast are pointers.  */
+      if (flag_lvalue_cast_assign
+         && TREE_CODE (ref) == NOP_EXPR
+         && string && string[0] == 'a'
+         && TREE_CODE (TREE_TYPE (ref)) == POINTER_TYPE
+         && TREE_CODE (TREE_TYPE (TREE_OPERAND (ref, 0))) == 
POINTER_TYPE
+         && lvalue_p (TREE_OPERAND (ref, 0)))
+       return 1;
+
        error ("non-lvalue in %s", string);
        return 0;
      }

although we clearly could use an 'enum lvalue_use' here as well.  At 
any rate, this patch causes the following to compile and run 
successfully:

Index: gcc/testsuite/g++.dg/ext/lvalue-cast-1.cpp
===================================================================
RCS file: gcc/testsuite/g++.dg/ext/lvalue-cast-1.cpp
diff -N gcc/testsuite/g++.dg/ext/lvalue-cast-1.cpp
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ gcc/testsuite/g++.dg/ext/lvalue-cast-1.cpp  22 Nov 2004 20:36:43 
-0000
@@ -0,0 +1,29 @@
+/* { dg-do run } */
+/* { dg-options "-flvalue-cast-assign" } */
+
+#include <stdlib.h>
+#define CHECK_IF(expr) if (!(expr)) abort ()
+
+static int global;
+
+void f(int &) { global = 35; }
+void f(const int &) { global = 78; }
+
+long long_arr[2];
+
+int main(void) {
+
+  char *p;
+
+  (long *)p = long_arr;
+  ((long *)p)++;
+  *(long *)p = -1;
+  *p = -2;
+  CHECK_IF(p[-1] == 0 && p[0] == -2 && p[1] == -1);
+
+  long x = 0;
+  f((int)x);
+  CHECK_IF(global == 78);
+
+  return 0;
+}

The rest of the patch (not shown) deals with defining/handling of the 
-flvalue-cast-assign flag.

Re: generalized lvalues -- patch outline

[Andrew Pinski]

On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote:

> On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:
>
>> To put it another way, I'm only concerned with cases where the 
>> compiler currently complains
>> about assigning to a non-lvalue, and the non-lvalue in question is a 
>> cast of an lvalue.
>
> Indeed, I now appear to have a mainline mod for C and C++ which allows 
> assignment to lvalue casts for pointer types.  What follows is a 
> high-level synopsis of what I did; if there is interest, I can whip up 
> a full-fledged patch, complete with docs.  Please let me know.


Just use a builtin as proposed by Nathan and others for the problem you
are trying to solve.  The syntax for casts as lvalue just looks bad.
The builtin can return a reference (yes even in the C front-end you
can have references [varargs is an example of which is used as
references in the front-end]).

Thanks,
Andrew Pinski

Re: generalized lvalues -- patch outline

[Ziemowit Laski]

On 22 Nov 2004, at 12.45, Andrew Pinski wrote:

>
> On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote:
>
>> On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:
>>
>>> To put it another way, I'm only concerned with cases where the 
>>> compiler currently complains
>>> about assigning to a non-lvalue, and the non-lvalue in question is a 
>>> cast of an lvalue.
>>
>> Indeed, I now appear to have a mainline mod for C and C++ which 
>> allows assignment to lvalue casts for pointer types.  What follows is 
>> a high-level synopsis of what I did; if there is interest, I can whip 
>> up a full-fledged patch, complete with docs.  Please let me know.
>
>
> Just use a builtin as proposed by Nathan and others for the problem you
> are trying to solve.  The syntax for casts as lvalue just looks bad.
> The builtin can return a reference (yes even in the C front-end you
> can have references [varargs is an example of which is used as
> references in the front-end]).

Here's hoping you'll get a chance to work with real third-party code 
some day... :-)

--Zem

Re: generalized lvalues -- patch outline

[Matt Austern]

On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote:

>
> On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote:
>
>> On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:
>>
>>> To put it another way, I'm only concerned with cases where the 
>>> compiler currently complains
>>> about assigning to a non-lvalue, and the non-lvalue in question is a 
>>> cast of an lvalue.
>>
>> Indeed, I now appear to have a mainline mod for C and C++ which 
>> allows assignment to lvalue casts for pointer types.  What follows is 
>> a high-level synopsis of what I did; if there is interest, I can whip 
>> up a full-fledged patch, complete with docs.  Please let me know.
>
>
> Just use a builtin as proposed by Nathan and others for the problem you
> are trying to solve.  The syntax for casts as lvalue just looks bad.
> The builtin can return a reference (yes even in the C front-end you
> can have references [varargs is an example of which is used as
> references in the front-end]).

Unfortunately, there is another reason for allowing some tamed version 
of assignment to casts: compatibility with other compilers.  Microsoft 
and CodeWarrior both allow this in one form or another.  (Microsoft for 
C only, CodeWarrior for C++ as well.  CodeWarrior only allows some 
limited forms of assignments to casts, and doesn't treat a cast as a 
true lvalue, so they still get overload resolution right.)

If it's possible to make some limited subset of this work without 
hurting C++ correctness, then I think we ought to do it.  We don't want 
to gratuitously break compatibility with other compilers.

			--Matt

Re: generalized lvalues -- patch outline

[Joe Buck]

On Mon, Nov 22, 2004 at 01:23:22PM -0800, Matt Austern wrote:
> Unfortunately, there is another reason for allowing some tamed version 
> of assignment to casts: compatibility with other compilers.  Microsoft 
> and CodeWarrior both allow this in one form or another.  (Microsoft for 
> C only, CodeWarrior for C++ as well.  CodeWarrior only allows some 
> limited forms of assignments to casts, and doesn't treat a cast as a 
> true lvalue, so they still get overload resolution right.)

Does CodeWarrior document the semantics of their extension?
 

Re: generalized lvalues -- patch outline

[Matt Austern]

On Nov 22, 2004, at 1:39 PM, Joe Buck wrote:

> On Mon, Nov 22, 2004 at 01:23:22PM -0800, Matt Austern wrote:
>> Unfortunately, there is another reason for allowing some tamed version
>> of assignment to casts: compatibility with other compilers.  Microsoft
>> and CodeWarrior both allow this in one form or another.  (Microsoft 
>> for
>> C only, CodeWarrior for C++ as well.  CodeWarrior only allows some
>> limited forms of assignments to casts, and doesn't treat a cast as a
>> true lvalue, so they still get overload resolution right.)
>
> Does CodeWarrior document the semantics of their extension?

I'm trying to find  that out.  It's taking me a while, I'm afraid, 
partly because I'm not all that familiar with their documentation. I 
agree that's an important question.  Another important question that I 
don't know the answer to: are there other compilers that accept some 
form of this extension?  I wouldn't be surprised; lots of people have 
MS-compatibility modes.

One oddity I've found is that CW allows this:
   int x;
   int* p = x;
   char c;
   (char*) p = &c;

but not this:
   int x;
   (char) x = 'a';

And, as I said, they do choose the correct overload when you pass 
((char*) p) to a function that's overloaded on char*& and  char* 
const&.

			--Matt

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

| One oddity I've found is that CW allows this:
|    int x;
|    int* p = x;
|    char c;
|    (char*) p = &c;
| 
| but not this:
|    int x;
|    (char) x = 'a';
| 
| And, as I said, they do choose the correct overload when you pass
| ((char*) p) to a function that's overloaded on char*& and  char*
| const&.

I'm surprised that such efforts are being spent to resurect that
abomination, when the C++ language already made clear provisions

    int x;
    int* p = x;
    char c;
    reinterpret_cast<char*&>(p) = &c;

or
    int x;
    reinterpret_cast<char&>(x) = 'a';

to mark those dubious constructs.

I offer

    template<class T, class U, class T>
    inline void
    sheat(U& u, V v)
    {
       reinterpret_cast<T&>(u) = v;
    }

as a free replacement of that abomination resurection.

Please, let's keep this straight.  It is already in the language; we
do not need to overload existing syntax in a way that conflict with
standard semantics.

cast-as-lvalue must go.

-- Gaby
   
   

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

| On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote:
| 
| >
| > On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote:
| >
| >> On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:
| >>
| >>> To put it another way, I'm only concerned with cases where the
| >>> compiler currently complains
| >>> about assigning to a non-lvalue, and the non-lvalue in question is
| >>> a cast of an lvalue.
| >>
| >> Indeed, I now appear to have a mainline mod for C and C++ which
| >> allows assignment to lvalue casts for pointer types.  What follows
| >> is a high-level synopsis of what I did; if there is interest, I can
| >> whip up a full-fledged patch, complete with docs.  Please let me
| >> know.
| >
| >
| > Just use a builtin as proposed by Nathan and others for the problem you
| > are trying to solve.  The syntax for casts as lvalue just looks bad.
| > The builtin can return a reference (yes even in the C front-end you
| > can have references [varargs is an example of which is used as
| > references in the front-end]).
| 
| Unfortunately, there is another reason for allowing some tamed version
| of assignment to casts: compatibility with other compilers.  Microsoft
| and CodeWarrior both allow this in one form or another.  (Microsoft
| for C only, CodeWarrior for C++ as well.  CodeWarrior only allows some
| limited forms of assignments to casts, and doesn't treat a cast as a
| true lvalue, so they still get overload resolution right.)

I fear there is a circular reasoning here: compilers tend to be
bug+feature compatible; there are high chances that those mentioned
compiler implement that dubious construct because gcc invented them in
the first place.  Now, saying those compilers implement that questionable
construct as a reason to resurect that abomination does not sound
right to me.

-- Gaby

Re: generalized lvalues -- patch outline

[Mike Stump]

On Nov 22, 2004, at 3:57 PM, Gabriel Dos Reis wrote:
> I fear there is a circular reasoning here

I suspect the same thing, but do not know.

Re: generalized lvalues -- patch outline

[Kai Henningsen]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 23.11.04 in <m38y8to2sz.fsf@uniton.integrable-solutions.net>:

> Matt Austern <austern@apple.com> writes:
>
> | On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote:
> |
> | >
> | > On Nov 22, 2004, at 3:39 PM, Ziemowit Laski wrote:
> | >
> | >> On 19 Nov 2004, at 17.50, Ziemowit Laski wrote:
> | >>
> | >>> To put it another way, I'm only concerned with cases where the
> | >>> compiler currently complains
> | >>> about assigning to a non-lvalue, and the non-lvalue in question is
> | >>> a cast of an lvalue.
> | >>
> | >> Indeed, I now appear to have a mainline mod for C and C++ which
> | >> allows assignment to lvalue casts for pointer types.  What follows
> | >> is a high-level synopsis of what I did; if there is interest, I can
> | >> whip up a full-fledged patch, complete with docs.  Please let me
> | >> know.
> | >
> | >
> | > Just use a builtin as proposed by Nathan and others for the problem you
> | > are trying to solve.  The syntax for casts as lvalue just looks bad.
> | > The builtin can return a reference (yes even in the C front-end you
> | > can have references [varargs is an example of which is used as
> | > references in the front-end]).
> |
> | Unfortunately, there is another reason for allowing some tamed version
> | of assignment to casts: compatibility with other compilers.  Microsoft
> | and CodeWarrior both allow this in one form or another.  (Microsoft
> | for C only, CodeWarrior for C++ as well.  CodeWarrior only allows some
> | limited forms of assignments to casts, and doesn't treat a cast as a
> | true lvalue, so they still get overload resolution right.)
>
> I fear there is a circular reasoning here: compilers tend to be
> bug+feature compatible; there are high chances that those mentioned
> compiler implement that dubious construct because gcc invented them in
> the first place.  Now, saying those compilers implement that questionable
> construct as a reason to resurect that abomination does not sound
> right to me.

That's a somewhat circular history, but I can't see any circular  
reasoning. If the goal is (say) MS compatibility, it doesn't matter if MS  
is the way it is because it wanted to be somewhat gcc compatible, or  
because they independently had the same idea, or whatever. It just matters  
that they are the way they are.

In any case, *if* something like that comes back, I think it should be  
done this way:

1. To get it, you need an explicit flag of some kind - it's not there by  
default, so we have a guarantee that it doesn't hurt programs which don't  
use it. (I have no preferences as to what flag would be appropriate, just  
that it be off by default.)

2. It is defined exactly what it does, preferrably as a syntactic  
transform to a standard (or at least different) language construct (this  
also helps people who want to get rid of it).

For example (and I don't claim this is the semantic it ought to have),

        modification((type)lvalue)

        ->

        ({
                type __tmp = (type)lvalue;
                modification(__tmp);
                lvalue = (typeof(lvalue))__tmp;
                lvalue;
        })

(and similarly for any other allowed general lvalue constructs).

MfG Kai

Re: generalized lvalues -- patch outline

[Mark Mitchell]

Matt Austern wrote:
> On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote:
> 

> If it's possible to make some limited subset of this work without 
> hurting C++ correctness, then I think we ought to do it.  We don't want 
> to gratuitously break compatibility with other compilers.

I don't necessarily agree.

I understand why that's important to Apple, but I'm not sure it's a 
mission priority for the FSF.  We know that this kind of thing makes for 
lots of bugs, and I'm sure that a mission priority is having relatively 
few bugs.

I think that maybe the SC needs to give an opinion, not on this 
extension, but on the overall goal of MSVC/CodeWarrior/... compatibility.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: generalized lvalues -- patch outline

[Matt Austern]

On Nov 22, 2004, at 4:09 PM, Mark Mitchell wrote:

> Matt Austern wrote:
>> On Nov 22, 2004, at 12:45 PM, Andrew Pinski wrote:
>
>> If it's possible to make some limited subset of this work without 
>> hurting C++ correctness, then I think we ought to do it.  We don't 
>> want to gratuitously break compatibility with other compilers.
>
> I don't necessarily agree.
>
> I understand why that's important to Apple, but I'm not sure it's a 
> mission priority for the FSF.  We know that this kind of thing makes 
> for lots of bugs, and I'm sure that a mission priority is having 
> relatively few bugs.
>
> I think that maybe the SC needs to give an opinion, not on this 
> extension, but on the overall goal of MSVC/CodeWarrior/... 
> compatibility.

Partly depends on what the value of "..." actually is.  I'd be 
interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
support this extension.

			--Matt

Re: generalized lvalues -- patch outline

[Mark Mitchell]

Matt Austern wrote:

> Partly depends on what the value of "..." actually is.  I'd be 
> interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
> support this extension.

I bet EDG does in its GCC-compatibility mode. :-)

It does not accept this code in its default mode.  (By default, I do not 
mean "strict ANSI" ; I mean the mode you get when you just say "eccp" 
with no options.)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: generalized lvalues -- patch outline

[Dale Johannesen]

Matt Austern wrote:

> Partly depends on what the value of "..." actually is.  I'd be 
> interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
> support this extension.

The construct occurs in the 176.gcc SPECmark, so I bet support is quite 
widespread,
at least for C.

Re: generalized lvalues -- patch outline

[Mark Mitchell]

Dale Johannesen wrote:
> Matt Austern wrote:
> 
>> Partly depends on what the value of "..." actually is.  I'd be 
>> interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
>> support this extension.
> 
> 
> The construct occurs in the 176.gcc SPECmark, so I bet support is quite 
> widespread,
> at least for C.

Heh. That's the nth bit of invalid code in 176.gcc, for some reasonably 
large value of n.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: generalized lvalues -- patch outline

[Andrew Pinski]

On Nov 22, 2004, at 8:28 PM, Dale Johannesen wrote:

> Matt Austern wrote:
>
>> Partly depends on what the value of "..." actually is.  I'd be 
>> interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
>> support this extension.
>
> The construct occurs in the 176.gcc SPECmark, so I bet support is 
> quite widespread, at least for C.

I was in obstack.h which is not directly directly part of gcc.
It is part of glibc.  The first copywrite on that file is for 1988
which a year after the copywrite of gcc.c, 1987. Maybe it was
originally of gcc but it is no longer.

-- Pinski

Re: generalized lvalues -- patch outline

[Dale Johannesen]

On Nov 22, 2004, at 5:36 PM, Andrew Pinski wrote:

>
> On Nov 22, 2004, at 8:28 PM, Dale Johannesen wrote:
>
>> Matt Austern wrote:
>>
>>> Partly depends on what the value of "..." actually is.  I'd be 
>>> interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
>>> support this extension.
>>
>> The construct occurs in the 176.gcc SPECmark, so I bet support is 
>> quite widespread, at least for C.
>
> I was in obstack.h which is not directly directly part of gcc.
> It is part of glibc.  The first copywrite on that file is for 1988
> which a year after the copywrite of gcc.c, 1987. Maybe it was
> originally of gcc but it is no longer.

Maybe so, but the file is included as part of the 176.gcc benchmark, 
and caused
compilation errors when gcc dropped support for this (mis)feature.

Re: generalized lvalues -- patch outline

[Andrew Pinski]

On Nov 22, 2004, at 8:42 PM, Dale Johannesen wrote:

>> It was in obstack.h which is not directly directly part of gcc.
>> It is part of glibc.  The first copywrite on that file is for 1988
>> which a year after the copywrite of gcc.c, 1987. Maybe it was
>> originally of gcc but it is no longer.
>
> Maybe so, but the file is included as part of the 176.gcc benchmark, 
> and caused
> compilation errors when gcc dropped support for this (mis)feature.

I had forgot one thing is that it was done conditional for GNUC
which seems wrong to me for a SPEC test :).

Some how this sliped in a SPEC test.

-- Pinski

Re: generalized lvalues -- patch outline

[Dale Johannesen]

On Nov 22, 2004, at 5:45 PM, Andrew Pinski wrote:
> On Nov 22, 2004, at 8:42 PM, Dale Johannesen wrote:
>
>>> It was in obstack.h which is not directly directly part of gcc.
>>> It is part of glibc.  The first copywrite on that file is for 1988
>>> which a year after the copywrite of gcc.c, 1987. Maybe it was
>>> originally of gcc but it is no longer.
>>
>> Maybe so, but the file is included as part of the 176.gcc benchmark, 
>> and caused
>> compilation errors when gcc dropped support for this (mis)feature.
>
> I had forgot one thing is that it was done conditional for GNUC
> which seems wrong to me for a SPEC test :).

Not exactly, it's true there's code conditional on GNUC, but both
branches use casts as lvalues.  (The now-available src.alt for
this problem only fixes the GNUC branch; presumably, gcc is
the only interesting compiler that won't take this.)

And yes, it is wrong for a SPEC test, but this code is hardly
ever executed in the benchmark.

Re: generalized lvalues -- patch outline

[Marcus G. Daniels]

Dale Johannesen wrote:

> Maybe so, but the file is included as part of the 176.gcc benchmark, 
> and caused
> compilation errors when gcc dropped support for this (mis)feature.

Fwiw, I ran in to the problem with an Objective C application.   It's 
convenient to store predispatched methods as function pointers, with all 
of their argument types.  However, the Objective method lookup methods 
return a generic IMP type which doesn't have that information.  So 
casting on the LHS means that the pointer is stored to the right 
function pointer type, but the RHS is doesn't need to reiterate it (the 
function pointer can be quite complicated). 

Re: generalized lvalues -- patch outline

[Eric Botcazou]

> Partly depends on what the value of "..." actually is.  I'd be
> interested in seeing whether other compilers (EDG? IBM? Sun? HP?)
> support this extension.

poog% cat ext.c
void foo(char *p)
{
  *((long *) p)++ = 1;
}

poog% cc -S ext.c
"ext.c", line 3: warning: a cast does not yield an lvalue

poog% cc -V
cc: Sun C 5.5 Patch 112760-14 2004/09/28

The assembly code looks correct (full word stored, p is incremented by 4).

-- 
Eric Botcazou

Re: generalized lvalues -- patch outline

[Aaron W. LaFramboise]

Matt Austern wrote:

> Partly depends on what the value of "..." actually is.  I'd be 
> interested in seeing whether other compilers (EDG? IBM? Sun? HP?) 
> support this extension.

Borland 5.5.1 C/C++ supports it, with a non-fatal warning "Nonportable
pointer conversion in function main," but only in C mode.


Aaron W. LaFramboise

Re: generalized lvalues -- patch outline

[Nathan Sidwell]

Ziemowit Laski wrote:
> Indeed, I now appear to have a mainline mod for C and C++ which allows 
> assignment to lvalue casts for pointer types.  What follows is a 
> high-level synopsis of what I did; if there is interest, I can whip up a 
> full-fledged patch, complete with docs.  Please let me know.

Please describe the semantics *in detail* of what you are trying to
achieve.  Why are the modify-assignment operators not allowed? That
appears non-orthogonal.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: generalized lvalues -- patch outline

[Ziemowit Laski]

On 22 Nov 2004, at 13.01, Nathan Sidwell wrote:

> Ziemowit Laski wrote:
>> Indeed, I now appear to have a mainline mod for C and C++ which 
>> allows assignment to lvalue casts for pointer types.  What follows is 
>> a high-level synopsis of what I did; if there is interest, I can whip 
>> up a full-fledged patch, complete with docs.  Please let me know.
>
> Please describe the semantics *in detail* of what you are trying to
> achieve.  Why are the modify-assignment operators not allowed? That
> appears non-orthogonal.

Modify-assignment is (or should be; I'll check) allowed.

The semantics are that a C-style cast of an lvalue will itself be 
treated as an lvalue under the following circumstances:
   - The lvalue cast does not induce a type conversion (if it does, then 
we use the type conversion instead);
   - The lvalue cast is being assigned to, incremented or decremented;
   - The lvalue is of a pointer type, and is being cast to a pointer 
type.  (This will need to be relaxed somewhat should people desire 
Microsoft compatibility, at least for C.)

Of course, all of this only with the -flvalue-cast-assign flag 
specified.

--Zem

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Ziemowit Laski <zlaski@apple.com> writes:

| The semantics are that a C-style cast of an lvalue will itself be
| treated as an lvalue under the following circumstances:
|    - The lvalue cast does not induce a type conversion (if it does,
| then we use the type conversion instead);
|    - The lvalue cast is being assigned to, incremented or decremented;
|    - The lvalue is of a pointer type, and is being cast to a pointer
| type.  (This will need to be relaxed somewhat should people desire
| Microsoft compatibility, at least for C.)

This is spelt reinterpret_cast in C++.  Please do not overload the
already confusing syntax with yet another confusing, dubious meaning.

I strongly object to the patch and any form to resurect the
cast-as-lvalue abomination.

-- Gaby

Re: generalized lvalues -- patch outline

[Nathan Sidwell]

Ziemowit Laski wrote:

> The semantics are that a C-style cast of an lvalue will itself be 
> treated as an lvalue under the following circumstances:

Thanks for your description, but I find it incomplete.

>   - The lvalue cast does not induce a type conversion (if it does, then 
> we use the type conversion instead);

You can't possibly mean this.  If the cast does not change the type, then
there's no reason to have it there.  Clearly some type conversions are
permitted and some not -- please be specific about which.  May be
you meant integral conversion, maybe you meant integral-pointer conversions
maybe you meant integral promotion ...

>   - The lvalue cast is being assigned to, incremented or decremented;
... or modified.  What is the bitrepresentation of the lvalue?  Is it
that of the newly specified type, or is the static type of the location?
(I.e. what would a C interpreter that tracks dynamic type say about
that lvalue's type.)

>   - The lvalue is of a pointer type, and is being cast to a pointer 
> type.
ok, so this answers my questions about point 1. Any pointer type? Like
the disallowed func->object conversion in C++? What about references
and/or references to pointer types?  Does array/function->pointer
decay occur? It might make sense to restrict the original lvalue
type to 'void *'.

Are there any restrictions on the original lvalue that is being cast?
Is this extension composable? For instance what about the following,
	#define MAGIC_REGISTER ((void *)p)
	(int *)MAGIC_REGISTER += 2

What about
	(expr, (int *)p) = something
in C++?  In C++ operator, is an lvalue if its second operand is an
lvalue. Similarly for ?:

Have you thought about specifying this in terms of a rewriting rule?
Do you have an analysis of interaction with existing features? What
programming errors would fall into this?

 >  (This will need to be relaxed somewhat should people desire
> Microsoft compatibility, at least for C.)
ahh, this leads me on to a rationale.  Why do you want this extension?
I see 6 different possible rationales. Are they all applicable?

1) Microsoft VC++ compatibility.  What are the specifications of this
extension?  (I see Matt is trying to find out.)  If this is the reason,
the whole of that extension should be implemented, and it should be enabled
on the existing -fms-extensions flag.

2) CodeWarrior compatibility. Same questions.  Is the CW extension exactly
the same as the VC++ extension?  There should be a -fcw-extensions flag
if we want to go down that route.

3) It is used in Apple's code base.  Mike Stump posted some numbers.  Can
you provide Apple's coding guidelines that document where this extension
can be used, and what the semantics are presumed to be?  I understand
the Linux kernel had some uses, but they have all been removed in the 2.6
series, because of their removal from gcc.  I have no idea on the relative
task sizes of removing it from Linux's and Apple's code base.

4) It is in use in other code that is 'out there'.  What code? Give
examples.  Given that one of the biggest bits (Linux kernel) has been
cleaned, this other code needs to be widely used and difficult to clean.
Andrew, what fraction of 3.4 bug reports concern this feature? (Does the
C FE give a deprecated warning, or are C users in the dark?)

5) Some ObjC/ObjC++ garbage collection proposal.  Other syntaxes have been
proposed.  I've not seen a detailed description of this proposal.

6) It leads to clearer, more understandable code.  It seems to me the
only thing that would be clearer is
	void *p = something;
	(int *)p += offset;
... maybe.  I do not find this compelling.  This code is what one finds
in memory allocators, and their implementation is few and far between.
In an allocator one would either make P a 'char *' or provide an inline
function/macro to do the adjustment.

I do not like the idea of special flags per extension.  That way lies
N^2 different 'interesting' failure modes.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: generalized lvalues -- patch outline

[Michael Matz]

Hi,

On Tue, 23 Nov 2004, Nathan Sidwell wrote:

> 4) It is in use in other code that is 'out there'.  What code? Give
>    examples.  Given that one of the biggest bits (Linux kernel) has been
>    cleaned,

How do you know the linux kernel was the biggest bit, when you don't know 
the other software?

FWIW, this extension is used in at least (determined from just looking at 
the compiler errors):
wine, elfutils, rpm, freeglut, dietlibc, openswan, xv, xine and 50 other 
packages.


Ciao,
Michael.

Re: generalized lvalues -- patch outline

[Daniel Berlin]

> FWIW, this extension is used in at least (determined from just looking at
> the compiler errors):
> wine, elfutils, rpm, freeglut, dietlibc, openswan, xv, xine and 50 other
> packages.

When you say used the extension, do you mean *intentionally* (IE it's in 
code that is part of the package), or is the extension part of code they 
include/link with from other packages (ie glibc, etc)

Re: generalized lvalues -- patch outline

[Michael Matz]

Hi,

On Tue, 23 Nov 2004, Daniel Berlin wrote:

> > FWIW, this extension is used in at least (determined from just looking at
> > the compiler errors):
> > wine, elfutils, rpm, freeglut, dietlibc, openswan, xv, xine and 50 other
> > packages.
> 
> When you say used the extension, do you mean *intentionally* (IE it's in code
> that is part of the package), or is the extension part of code they
> include/link with from other packages (ie glibc, etc)

Those of them at which I looked, use it intentionally (mislead perhaps,
but intentionally).  Sometimes it's in specialised code, like for instance
image manipulation (i.e. sweeping over an array), sometimes it's in
package generic code (for instance I saw list iterator macros, which use a
generic variable, but which are type indepependend, to implement generics
in C).  I didn't see it used in something like system-wide headers
(although IIRC some Sun xdr headers once contained such code, but I think
that got fixed meanwhile).

In wine for instance it's in generated code (proxy and stub functions for 
implementing the COM interfaces, i.e. all kinds of marshalling).  The use 
here usually is of the increment form (one pointer walking an array, 
incremented by different amounts depending on the type).

Sure, this all could be fixed by changing all of the 50+ packages.  Or by 
implementing a very constrained form of the extension in GCC.

The only C++ packages in which I see this is alsamixergui, chasen, 
knights, libebml and licq, so I personally would be thankful already for 
having such extension only in C.

Practically speaking 4.0 is currently strictly less usefull in some 
aspects for the average C programmer.


Ciao,
Michael.

Re: generalized lvalues -- patch outline

[Andrew Pinski]

On Nov 23, 2004, at 9:56 AM, Michael Matz wrote:

> Hi,Practically speaking 4.0 is currently strictly less usefull in some
> aspects for the average C programmer.

The average C programmer would not have thought to use this extension
unless they just decided one day to try it or they actually read the
gcc documentation (which I know almost nobody does).  (We keep getting
bug reports about invalid C++ which explicitly added to the changes
page and in the bug section of the documentation but those people
seems not bothered to read those places.)

if you had the following:

((int*)a)++;

the better idea would be:

char *a1 = (char*)a;
a1 += sizeof(int)/sizeof(char);
a = (typeof(a))(a1);

-- Pinski

Re: generalized lvalues -- patch outline

[Michael Matz]

Hi,

On Tue, 23 Nov 2004, Andrew Pinski wrote:

> if you had the following:
> 
> ((int*)a)++;
> 
> the better idea would be:
> 
> char *a1 = (char*)a;
> a1 += sizeof(int)/sizeof(char);
> a = (typeof(a))(a1);

Ah, yes ;-)

I disagree.  The better idea would have been if the C language would allow 
for the first construct.  It's shorter, and by giving this rewriting rule 
seems also to be easy to define.


Ciao,
Michael.

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

| Hi,
| 
| On Tue, 23 Nov 2004, Andrew Pinski wrote:
| 
| > if you had the following:
| > 
| > ((int*)a)++;
| > 
| > the better idea would be:
| > 
| > char *a1 = (char*)a;
| > a1 += sizeof(int)/sizeof(char);
| > a = (typeof(a))(a1);
| 
| Ah, yes ;-)
| 
| I disagree.  The better idea would have been if the C language would allow 
| for the first construct.  It's shorter, and by giving this rewriting rule 
| seems also to be easy to define.

Short is good, when it does not introduce confusion and unnecessary
complexity. 
Specialized macros for such questionable constructs are better.

-- Gaby

Re: generalized lvalues -- patch outline

[Steve Naroff]

On Nov 23, 2004, at 7:06 AM, Andrew Pinski wrote:

>
> On Nov 23, 2004, at 9:56 AM, Michael Matz wrote:
>
>> Hi,Practically speaking 4.0 is currently strictly less usefull in some
>> aspects for the average C programmer.
>
> The average C programmer would not have thought to use this extension
> unless they just decided one day to try it or they actually read the
> gcc documentation (which I know almost nobody does).

I believe this is true, however some programmers end up using gcc 
extensions without knowing they are extensions (e.g. variable length 
arrays, non-constant initializers, etc.). This happens for the same 
reason you cite - many programmers don't study the language standard 
(or compile with the strict ANSI modes). Since many of the extensions 
don't add any new syntax, it is easy to become dependent on these 
features without realizing it.

Like you, I'd love to see this feature removed. Unfortunately, I am 
concerned about breaking code. Language features are like API's...they 
are part of the contract we make with our developers. Years ago, I felt 
inclined to disable all gcc extensions for Apple's compiler. I didn't 
do it because I knew there would be fallout. Unfortunately, this is a 
great example of why the thought crossed my mind...

btw...I contacted Andreas Hommel (author of the CW C++ front-end). He 
added generalized lvalue support for gcc compatibility (though they 
appear to get the right answer for the cases I've been forwarded, 
whereas gcc doesn't). He has no affinity for the feature and would 
consider removing it...he has the same concern as I just 
described...breaking code.

> (We keep getting
> bug reports about invalid C++ which explicitly added to the changes
> page and in the bug section of the documentation but those people
> seems not bothered to read those places.)
>
> if you had the following:
>
> ((int*)a)++;
>
> the better idea would be:
>
> char *a1 = (char*)a;
> a1 += sizeof(int)/sizeof(char);
> a = (typeof(a))(a1);
>
> -- Pinski
>

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Steve Naroff <snaroff@apple.com> writes:

| On Nov 23, 2004, at 7:06 AM, Andrew Pinski wrote:
| 
| >
| > On Nov 23, 2004, at 9:56 AM, Michael Matz wrote:
| >
| >> Hi,Practically speaking 4.0 is currently strictly less usefull in some
| >> aspects for the average C programmer.
| >
| > The average C programmer would not have thought to use this extension
| > unless they just decided one day to try it or they actually read the
| > gcc documentation (which I know almost nobody does).
| 
| I believe this is true, however some programmers end up using gcc
| extensions without knowing they are extensions (e.g. variable length
| arrays, non-constant initializers, etc.). This happens for the same
| reason you cite - many programmers don't study the language standard

They need not study the language standard -- which often is written in
obscure jargon with impenetrable logic.  They just need learn programming.
Compilers that accept, by default, not-well-taught extensions are
justifiably of no help.

-- Gaby

Re: generalized lvalues -- patch outline

[Eric Botcazou]

> The average C programmer would not have thought to use this extension
> unless they just decided one day to try it or they actually read the
> gcc documentation (which I know almost nobody does).

I disagree: *((int *)p)++ was accepted by virtually all the good old 
compilers: GCC 2.x, Microsoft, Borland, Watcom.  This is a natural idiom when 
you're manipulating images with different color depths:

  char *p = bitmap->data;

  switch (color_depth)
  {
    case 8:
      *p++ = c;
      break;

    case 15:
    case 16:
      *((short *)p)++ = c;
      break;

    case 32:
      *((int *)p)++ = c;
      break;
   } 

Of course, nowadays everything is 32-bit so... :-)

And

char *a1 = (char*)a;
a1 += sizeof(int)/sizeof(char);
a = (typeof(a))(a1);

is plain ugly.

-- 
Eric Botcazou

Re: generalized lvalues -- patch outline

[Paul Koning]

>>>>> "Eric" == Eric Botcazou <ebotcazou@libertysurf.fr> writes:

 >> The average C programmer would not have thought to use this
 >> extension unless they just decided one day to try it or they
 >> actually read the gcc documentation (which I know almost nobody
 >> does).

 Eric> I disagree: *((int *)p)++ was accepted by virtually all the
 Eric> good old compilers: GCC 2.x, Microsoft, Borland, Watcom.  This
 Eric> is a natural idiom when you're manipulating images with
 Eric> different color depths ...

... or doing alignment-optimized copying.  I've seen this notation in
our code, and I'm pretty sure the author didn't get it from the GCC
docs.  It's a natural thing to write -- unless you ARE a language
lawyer and understand the hairy details of precisely what is an lvalue
and what is not.

    paul

Re: generalized lvalues -- patch outline

[Andreas Schwab]

Paul Koning <pkoning@equallogic.com> writes:

>>>>>> "Eric" == Eric Botcazou <ebotcazou@libertysurf.fr> writes:
>
>  >> The average C programmer would not have thought to use this
>  >> extension unless they just decided one day to try it or they
>  >> actually read the gcc documentation (which I know almost nobody
>  >> does).
>
>  Eric> I disagree: *((int *)p)++ was accepted by virtually all the
>  Eric> good old compilers: GCC 2.x, Microsoft, Borland, Watcom.  This
>  Eric> is a natural idiom when you're manipulating images with
>  Eric> different color depths ...
>
> ... or doing alignment-optimized copying.  I've seen this notation in
> our code, and I'm pretty sure the author didn't get it from the GCC
> docs.  It's a natural thing to write -- unless you ARE a language
> lawyer and understand the hairy details of precisely what is an lvalue
> and what is not.

... and what strict aliasing can do to ruin your code. :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: generalized lvalues -- patch outline

[Thomas Kunert]

Paul Koning wrote:
>>>>>>"Eric" == Eric Botcazou <ebotcazou@libertysurf.fr> writes:
> 
> 
>  >> The average C programmer would not have thought to use this
>  >> extension unless they just decided one day to try it or they
>  >> actually read the gcc documentation (which I know almost nobody
>  >> does).
> 
>  Eric> I disagree: *((int *)p)++ was accepted by virtually all the
>  Eric> good old compilers: GCC 2.x, Microsoft, Borland, Watcom.  This
>  Eric> is a natural idiom when you're manipulating images with
>  Eric> different color depths ...
> 
> ... or doing alignment-optimized copying.  I've seen this notation in
> our code, and I'm pretty sure the author didn't get it from the GCC
> docs.  It's a natural thing to write -- unless you ARE a language
> lawyer and understand the hairy details of precisely what is an lvalue
> and what is not.
> 

A union is the correct solution.

union {
    char* c;
    int* i;
    short* s;
} p;

*p.i++;

TK.

Re: generalized lvalues -- patch outline

[Nathan Sidwell]

Thomas Kunert wrote:

> A union is the correct solution.
> 
> union {
>    char* c;
>    int* i;
>    short* s;
> } p;
> 
> *p.i++;

This suggests an excellent model for describing this extension. The lvalue
cast behaves as if the object is a union of two fields.  One field with
the original type and the other field with the cast-to type.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: generalized lvalues -- patch outline

[Thomas Kunert]

Nathan Sidwell wrote:
> Thomas Kunert wrote:
> 
>> A union is the correct solution.
>>
>> union {
>>    char* c;
>>    int* i;
>>    short* s;
>> } p;
>>
>> *p.i++;
> 
> 
> This suggests an excellent model for describing this extension. The lvalue
> cast behaves as if the object is a union of two fields.  One field with
> the original type and the other field with the cast-to type.
> 
> nathan
> 

This doesn't work for C++, does it?

TK.

Re: generalized lvalues -- patch outline

[Paul Koning]

>>>>> "Thomas" == Thomas Kunert <kunert@physik.tu-dresden.de> writes:

 Thomas> Paul Koning wrote:
 >>>>>>> "Eric" == Eric Botcazou <ebotcazou@libertysurf.fr> writes:
 >> 
 >> 
 >> >> The average C programmer would not have thought to use this >>
 >> extension unless they just decided one day to try it or they >>
 >> actually read the gcc documentation (which I know almost nobody >>
 >> does).
 >> 
 Eric> I disagree: *((int *)p)++ was accepted by virtually all the
 Eric> good old compilers: GCC 2.x, Microsoft, Borland, Watcom.  This
 Eric> is a natural idiom when you're manipulating images with
 Eric> different color depths ...
 >> ... or doing alignment-optimized copying.  I've seen this notation
 >> in our code, and I'm pretty sure the author didn't get it from the
 >> GCC docs.  It's a natural thing to write -- unless you ARE a
 >> language lawyer and understand the hairy details of precisely what
 >> is an lvalue and what is not.
 >> 

 Thomas> A union is the correct solution.

 Thomas> union { char* c; int* i; short* s; } p;

 Thomas> *p.i++;

But that depends on char* and int* having the same representation,
doesn't it?

	paul

Re: generalized lvalues -- patch outline

[Thomas Kunert]

Paul Koning wrote:
> 
>  Thomas> union { char* c; int* i; short* s; } p;
> 
>  Thomas> *p.i++;
> 
> But that depends on char* and int* having the same representation,
> doesn't it?
> 

Yes, that's of course right. I had forgotten about that, thanks for the reminder.

TK.

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

[...]

| The only C++ packages in which I see this is alsamixergui, chasen, 
| knights, libebml and licq, so I personally would be thankful already for 
| having such extension only in C.

Such C++ prckages can use reinterpret_cast<>.

C packages can use dedicated macros, if they really think the need
that sheating.   

| Practically speaking 4.0 is currently strictly less usefull in some 
| aspects for the average C programmer.

Well,  you and I have different notions of "average programmer".
Obvioulsy the cast-as-lvalue abomination is not something the averaget
programmer would jump into.

Probably, this sort of situations probably happen because some people
have been encouraged in conceiving programming as an activity of
throwing random codes to the compiler and see what happens.

:-(

-- Gaby

Re: generalized lvalues -- patch outline

[Michael Matz]

Hi,

On Tue, 23 Nov 2004, Gabriel Dos Reis wrote:

> Michael Matz <matz@suse.de> writes:
> 
> [...]
> 
> | The only C++ packages in which I see this is alsamixergui, chasen, 
> | knights, libebml and licq, so I personally would be thankful already for 
> | having such extension only in C.
> 
> Such C++ prckages can use reinterpret_cast<>.
> 
> C packages can use dedicated macros, if they really think the need
> that sheating.   

My point in the whole discussion is to avoid having to change 50+
packages.  If I'm (or whoever else is) going to fix them anyway, I can see
multiple ways.  So you suggesting some of those ways misses my point.

> | Practically speaking 4.0 is currently strictly less usefull in some 
> | aspects for the average C programmer.
> 
> Well,  you and I have different notions of "average programmer".

Yes.  Perhaps because I have to deal with many packages built by GCC my 
view of the average programmer is skewed to one side, because it's natural 
that I only see examples of how strange things programmers do.  Nobody 
calls me because his package compiles ;-)

> Probably, this sort of situations probably happen because some people
> have been encouraged in conceiving programming as an activity of
> throwing random codes to the compiler and see what happens.

Possible.  This is one of the ways to learn programming.  And despite what
the language standard says, to my eyes "(T*)p++" looks like a natural way
to write p+=sizeof(T), so I'm somewhat sympathetic to programmers using
this construct.


Ciao,
Michael.

Re: generalized lvalues -- patch outline

[Richard Guenther]

On Tue, 23 Nov 2004 16:57:58 +0100 (CET), Michael Matz <matz@suse.de> wrote:
> 
> 
> Hi,
> 
> On Tue, 23 Nov 2004, Gabriel Dos Reis wrote:
>
> >
> > Probably, this sort of situations probably happen because some people
> > have been encouraged in conceiving programming as an activity of
> > throwing random codes to the compiler and see what happens.
> 
> Possible.  This is one of the ways to learn programming.  And despite what
> the language standard says, to my eyes "(T*)p++" looks like a natural way
> to write p+=sizeof(T), so I'm somewhat sympathetic to programmers using
> this construct.

Especially as it would need

 p = (__typeof__(p))((char *)p + sizeof(T));

If you restrict *(T*)p++ to p of char* or void* type, how many broken packages
would be left?  I think at least those should be fixed.

Richard.

> Ciao,
> Michael.
>

Re: generalized lvalues -- patch outline

[Andreas Schwab]

Michael Matz <matz@suse.de> writes:

> And despite what the language standard says, to my eyes "(T*)p++" looks
> like a natural way to write p+=sizeof(T),

Actually it isn't, you missed the parens. :-)

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

| > Probably, this sort of situations probably happen because some people
| > have been encouraged in conceiving programming as an activity of
| > throwing random codes to the compiler and see what happens.
| 
| Possible.  This is one of the ways to learn programming.  And despite what
| the language standard says, to my eyes "(T*)p++" looks like a natural way
| to write p+=sizeof(T),

then, such packages deserve being broken loudly because the former is not
equivalent to the second, with ou without the abomination in question :-)

-- Gaby

Re: generalized lvalues -- patch outline

[Nathan Sidwell]

Michael Matz wrote:
> Hi,
> 
> On Tue, 23 Nov 2004, Nathan Sidwell wrote:
> 
> 
>>4) It is in use in other code that is 'out there'.  What code? Give
>>   examples.  Given that one of the biggest bits (Linux kernel) has been
>>   cleaned,
> 
> 
> How do you know the linux kernel was the biggest bit, when you don't know 
> the other software?
I thought the kernel is both one of the biggest things out there and one
of the bigger stressers of gcc. Therefore if that can be cleaned, your
'average' smaller package can be cleaned (for some value of average).
I'm willing to be corrected.

> FWIW, this extension is used in at least (determined from just looking at 
> the compiler errors):
> wine, elfutils, rpm, freeglut, dietlibc, openswan, xv, xine and 50 other 
> packages.
ok, that's quite a big list, thank you.  I don't suppose you know which
version of this extension they're using? :)  Will Ziemowit's restriction
to pointers satisfy them?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: generalized lvalues -- patch outline

[Michael Matz]

Hi,

On Tue, 23 Nov 2004, Nathan Sidwell wrote:

> > FWIW, this extension is used in at least (determined from just looking at
> > the compiler errors):
> > wine, elfutils, rpm, freeglut, dietlibc, openswan, xv, xine and 50 other
> > packages.
> ok, that's quite a big list, thank you.  I don't suppose you know which
> version of this extension they're using? :)

I did not look at all those packages, but from looking at some of them, 
and listening to my guts this would mostly by of the form

 *((T*)p)++ = x;

And sometimes also "(T*)p = x", especially in C code implementing 
something type-generic with macros (like all kinds of iterators).

> Will Ziemowit's restriction to pointers satisfy them?

I don't know for sure, but would be willing to try a patch in our build 
system.


Ciao,
Michael.

Re: generalized lvalues -- patch outline

[Matt Austern]

On Nov 23, 2004, at 6:02 AM, Nathan Sidwell wrote:

>> FWIW, this extension is used in at least (determined from just 
>> looking at the compiler errors):
>> wine, elfutils, rpm, freeglut, dietlibc, openswan, xv, xine and 50 
>> other packages.
> ok, that's quite a big list, thank you.  I don't suppose you know which
> version of this extension they're using? :)  Will Ziemowit's 
> restriction
> to pointers satisfy them?

I haven't looked at that list, but one data point: CW restricts this 
cast to pointers, so that's good enough for CW compatibility.  I guess 
we learned just today (thanks, Eric!) that Solaris supports some 
version of this extension, at least for C.  We don't yet know the 
boundaries of Sun's version of the extension.

			--Matt

Re: generalized lvalues -- patch outline

[Eric Botcazou]

> I haven't looked at that list, but one data point: CW restricts this
> cast to pointers, so that's good enough for CW compatibility.  I guess
> we learned just today (thanks, Eric!) that Solaris supports some
> version of this extension, at least for C.  We don't yet know the
> boundaries of Sun's version of the extension.

Since you so kindly asked... :-)

Sun seems to restrict it to pointers too, i.e. it rejects (short)v = 1 as well 
as:

void bar(unsigned long addr)
{
  *((int *)addr)++ = 1;
}

with:
"ext.c", line 8: a cast does not yield an lvalue
cc: acomp failed for ext.c


Here's the reaction of the C++ compiler:
poog% cat ext.C
void foo(char *p)
{
  *((long *) p)++ = 1;
}
poog% CC -S ext.C
"ext.C", line 3: Error: Operand for operator "++" must be an lvalue.
1 Error(s) detected.

-- 
Eric Botcazou

Re: generalized lvalues -- patch outline

[Ziemowit Laski]

On 23 Nov 2004, at 1.30, Nathan Sidwell wrote:

> Ziemowit Laski wrote:
>
>> The semantics are that a C-style cast of an lvalue will itself be 
>> treated as an lvalue under the following circumstances:
>
> Thanks for your description, but I find it incomplete.
>
>>   - The lvalue cast does not induce a type conversion (if it does, 
>> then we use the type conversion instead);
>
> You can't possibly mean this.  If the cast does not change the type, 
> then
> there's no reason to have it there.  Clearly some type conversions are
> permitted and some not -- please be specific about which.  May be
> you meant integral conversion, maybe you meant integral-pointer 
> conversions
> maybe you meant integral promotion ...

By "inducing a type conversion", I meant generating code to make the 
conversion happen, as in '(float)intValue'.  Perhaps I should have said 
'non-trivial type conversion' or some such.  In C, conversions among 
pointer types should always be trivial, but in C++, conversion 
operators could kick in.  In those non-trivial cases, we would disallow 
the lvalue cast.
>
>>   - The lvalue cast is being assigned to, incremented or decremented;
> ... or modified.  What is the bitrepresentation of the lvalue?  Is it
> that of the newly specified type, or is the static type of the 
> location?

Since we're talking about pointers, the bit representation does not 
change.  Microsoft also allows lvalue casts so long as the type being 
cast to is not larger than the original type (e.g., '(short)longValue' 
is OK whereas '(long)shortValue' is not); in those cases, I'm fairly 
certain
we want the bit layout of the newly specified type.

>>   - The lvalue is of a pointer type, and is being cast to a pointer 
>> type.
> ok, so this answers my questions about point 1. Any pointer type? Like
> the disallowed func->object conversion in C++? What about references
> and/or references to pointer types?  Does array/function->pointer
> decay occur? It might make sense to restrict the original lvalue
> type to 'void *'.

Just plain C pointers ('foo *', 'bar *'); no references and no 
pointers-to-members, although I see no reason why we should disallow 
arrays and function pointers.
>
> Are there any restrictions on the original lvalue that is being cast?

I don't understand this question -- what kind of restrictions 
could/should
there be?

> Is this extension composable? For instance what about the following,
> 	#define MAGIC_REGISTER ((void *)p)
> 	(int *)MAGIC_REGISTER += 2
>
> What about
> 	(expr, (int *)p) = something
> in C++?  In C++ operator, is an lvalue if its second operand is an
> lvalue. Similarly for ?:

I think the examples you give here should all work.
>
> Have you thought about specifying this in terms of a rewriting rule?

Under the conditions specified above,

          (foo)bar

could be rewritten to

          *((foo *)&bar)

> Do you have an analysis of interaction with existing features?

I don't, although I'm not sure what would constitute "analysis" in this 
context.
I suppose you can take the rewrite rule above and then try to see if 
the rewritten expression
would play nicely as an rvalue in other contexts; off the top of my 
head, I can't think of
situations where it would not, though I welcome others to poke holes in 
this theory.

One important thing to note is that the extension I'm proposing does 
not change existing, valid behavior; it only affects cases that 
currently (with TOT gcc 4.0) produce hard errors.

>  What
> programming errors would fall into this?

Are you asking, "how are programmers likely to misconstrue what this 
extension does"?  I think most programmers out there would probably be 
surprised that this is an extension at all, since most would expect 
something like

    (foo)bar = value;

to simply "work" :-); so probably the biggest pitfall would be that, 
even with the extension enabled, programmers will still get non-lvalue 
errors sometimes and then wonder why.

> Why do you want this extension?
> I see 6 different possible rationales. Are they all applicable?

Yes, they are all applicable, although any one of them taken separately 
is sufficient justification, IMO.  MS cnd CW compatibility is important 
because of code that is being brought over, but I don't think we 
necessarily have to implement each corner case of this extension as 
supported by these (and other) compilers (we could, but that would go 
way beyond what we are proposing here).  Rather, what we are concerned 
with is how the extensions tend to be used in real code.  And most 
existing usage, both in Apple's case and in examples cited by Michael 
Matz, has to do with pointer type manipulation.  So, even while I'm 
advocating this feature, I do not wish to bloat it unnecessarily.

--Zem

Re: generalized lvalues -- patch outline

[Joseph S. Myers]

On Tue, 23 Nov 2004, Ziemowit Laski wrote:

> Under the conditions specified above,
> 
>          (foo)bar
> 
> could be rewritten to
> 
>          *((foo *)&bar)

You seem to be implying that the address of a cast could be taken.  This 
was not part of the old GNU extension.

You are also implying that if "foo" and "typeof(bar)" are not types which 
may alias, then there is runtime undefined behavior by strict-aliasing 
rules.  I don't think this is what you intend.

> > Do you have an analysis of interaction with existing features?
> 
> I don't, although I'm not sure what would constitute "analysis" in this
> context.

Write down the textual amendments to C99+TC1+TC2 and C++03 which would 
introduce your feature.  Examine *every* reference to "lvalue" in either 
of those standards and explain how your changes interact with that 
reference.  That's a *minimum* of analysis that would be needed for this.

> Are you asking, "how are programmers likely to misconstrue what this extension
> does"?  I think most programmers out there would probably be surprised that
> this is an extension at all, since most would expect something like
> 
>    (foo)bar = value;
> 
> to simply "work" :-); so probably the biggest pitfall would be that, even with
> the extension enabled, programmers will still get non-lvalue errors sometimes
> and then wonder why.

People don't need to have read the standards to be aware that casts aren't 
lvalues; for example, having read K&R would suffice.  I don't think we 
should accept random junk just because someone who hasn't familiarised 
themselves with the language might throw it at the compiler: we should 
inform them of the problem with their code and thereby help them to learn 
the languages better.

The use in glibc's RPC headers was not using any actual part of the 
semantics of lvalue casts; it was accidental and e.g. Sun's RPC headers 
achieved the proper specification without needing any lvalue casts or 
similar junk.  I must suspect many other uses are similar.

People expect new major versions to break things.  4.0 is an excellent 
opportunity to deprecate or remove unwise features, of which lvalue casts 
were one.

> Yes, they are all applicable, although any one of them taken separately is
> sufficient justification, IMO.  MS cnd CW compatibility is important because

The removal of crufty code, improving the maintainability of the compiler, 
is sufficient justification for the removal of a dubious extension which 
does not add expressive power to the language.

-- 
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)

Re: generalized lvalues -- patch outline

[Eric Botcazou]

> The removal of crufty code, improving the maintainability of the compiler,
> is sufficient justification for the removal of a dubious extension which
> does not add expressive power to the language.

It's not that dubious since most compilers seem to have it, at least in the 
pointer case.  And no, please, don't say it's because they tried to play 
catch-up with GCC, I would not believe you.

And, from the user's viewpoint, this kind of argument has no merit anyway.

-- 
Eric Botcazou

Re: generalized lvalues -- patch outline

[Joseph S. Myers]

On Tue, 23 Nov 2004, Eric Botcazou wrote:

> It's not that dubious since most compilers seem to have it, at least in the 
> pointer case.  And no, please, don't say it's because they tried to play 
> catch-up with GCC, I would not believe you.
> 
> And, from the user's viewpoint, this kind of argument has no merit anyway.

One user's description of lvalue casts is "... there is absolutely zero 
point to them ... The whole extension is just braindamaged ... I bet 99% 
of the people on this list have no clue what the exact semantics of the 
above are." (Linus Torvalds in 
<http://seclists.org/lists/linux-kernel/2003/Dec/5431.html>).  I agree.  
(There may still be a case for the ObjC cases *only*, provided they can 
only be written in ObjC and ObjC++ and a different ObjC-specific tree code 
is used to represent them from the codes used for casts.)

-- 
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)

Re: generalized lvalues -- patch outline

[Eric Botcazou]

> One user's description of lvalue casts is "... there is absolutely zero
> point to them ... The whole extension is just braindamaged ... I bet 99%
> of the people on this list have no clue what the exact semantics of the
> above are." (Linus Torvalds in
> <http://seclists.org/lists/linux-kernel/2003/Dec/5431.html>).  I agree.

Note that Linus doesn't mention the pointer case.

Since we are at lkml exegesis, take a look at
http://www.kerneltraffic.org/kernel-traffic/kt20041009_276.html#3

<but Willy Tarreau replied, "Tell that to gcc developpers who constantly break 
compatibility between versions. I even have userland programs which do not 
compile anymore with gcc-3.3 and which I don't even know how to 
'fix' (workaround ?).">

-- 
Eric Botcazou

Re: generalized lvalues -- patch outline

[Steven Bosscher]

On Wednesday 24 November 2004 00:52, Eric Botcazou wrote:
> <but Willy Tarreau replied, "Tell that to gcc developpers who constantly
> break compatibility between versions. I even have userland programs which
> do not compile anymore with gcc-3.3 and which I don't even know how to
> 'fix' (workaround ?).">

Heh, that sounds very much like a complaint I got recently from
another suse developer, who told me he thinks that "icc is now
more compatible with gcc than gcc itself".  :-)

Gr.
Steven

Re: generalized lvalues -- patch outline

[Joseph S. Myers]

On Wed, 24 Nov 2004, Eric Botcazou wrote:

> http://www.kerneltraffic.org/kernel-traffic/kt20041009_276.html#3
> 
> <but Willy Tarreau replied, "Tell that to gcc developpers who constantly break 
> compatibility between versions. I even have userland programs which do not 
> compile anymore with gcc-3.3 and which I don't even know how to 
> 'fix' (workaround ?).">

If 3.3 is the problem version, lvalue casts aren't the issue; they are 
still present in 3.3.  (The backporting of the deprecation which was put 
in 3.3.4 is something I would consider dubious: though backporting a 
deprecation may be tempting and give users more warning, it also might 
break code that was working with that release series, which really should 
be avoided within a release series once it has first had a release: 
upgrading from a.b.c to a.b.c+1 should always be safe even with code using 
a feature that is going to go away.)

-- 
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)

Re: generalized lvalues -- patch outline

[Ian Lance Taylor]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

> On Wed, 24 Nov 2004, Eric Botcazou wrote:
> 
> > http://www.kerneltraffic.org/kernel-traffic/kt20041009_276.html#3
> > 
> > <but Willy Tarreau replied, "Tell that to gcc developpers who constantly break 
> > compatibility between versions. I even have userland programs which do not 
> > compile anymore with gcc-3.3 and which I don't even know how to 
> > 'fix' (workaround ?).">
> 
> If 3.3 is the problem version, lvalue casts aren't the issue; they are 
> still present in 3.3.  (The backporting of the deprecation which was put 
> in 3.3.4 is something I would consider dubious: though backporting a 
> deprecation may be tempting and give users more warning, it also might 
> break code that was working with that release series, which really should 
> be avoided within a release series once it has first had a release: 
> upgrading from a.b.c to a.b.c+1 should always be safe even with code using 
> a feature that is going to go away.)

Given that lvalue casts were actually removed after the 3.4 series,
and given that, whether you like it or not, they are in fact widely
used, I think that it was absolutely essential to get the warning into
3.3.4, so that people would have a chance to fix their bug before it
completely breaks.  I certainly agree that the warning should have
been in 3.3.0, or that the removal should have been pushed into 4.1.

Ian

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Ian Lance Taylor <ian@wasabisystems.com> writes:

| completely breaks.  I certainly agree that the warning should have
| been in 3.3.0, 

well, the time travelling machine is a bit expensive for me :-) :-)

-- Gaby

Re: generalized lvalues -- patch outline

[Matt Austern]

On Nov 25, 2004, at 12:30 PM, Gabriel Dos Reis wrote:

> Ian Lance Taylor <ian@wasabisystems.com> writes:
>
> | completely breaks.  I certainly agree that the warning should have
> | been in 3.3.0,
>
> well, the time travelling machine is a bit expensive for me :-) :-)

But it is still a serious concern.

I've gone back and forth on this question several times.  I think, and 
have always thought, that this is a bad extension (at least for C++) 
and that it was put in without enough thought.  There are other GNU 
extensions for which I'd say that too. But that can't be the end of the 
discussion.  The question is how we should remove an extension once 
we've decided that it's bad.  One extreme answer: you can't ever do it, 
because we must never break user code.  Another extreme answer: you 
should just remove it and not worry about the consequences, and anyone 
who was using a nonstandard extension deserves whatever they get.  I 
prefer something in the middle.

When we first started talking about this, a year ago, I assumed that we 
would have to phase out this extension over the course of three major 
releases.  I assumed we would start the removal process in 3.5, and the 
feature wouldn't be completely dead until 3.7.  Instead we're going 
from having the feature fully supported in 3.4.0 to having it 
completely gone in 4.0.  I'm concerned that we haven't given users 
adequate notice.  (Yes, I know we deprecated it in later releases in 
the 3.3.x and 3.4.x series.  But users can be forgiven for only looking 
at major releases.)

I changed my mind, and reluctantly agreed that immediate removal was 
the best option, because of what Joe Buck pointed out: that this wasn't 
a pure extension, but that it actually changed the meaning of legal C++ 
programs by causing them to select the wrong overload in some cases.  
This was a serious bug. Seen in that light, removal seemed like the 
only possible answer: obviously we have to fix bugs.

So we knew all of that a year ago.  I think we know two more things now.
  1. Other compilers implement this extension too.  I didn't know that.
  2. It's possible to tame this extension, to permit assignment-to-cast 
while still not treating casts as lvalue for the purpose of overload 
resolution.

What #1 suggests to me is that immediate removal was more unfriendly 
than we'd thought, and what #2 suggests is that immediate removal 
wasn't the only option.  We can fix the overload resolution bug, keep 
the feature for the cases where people are likely to have used it, 
deprecate it in 4.0, and remove it in a later major release.

                  --Matt

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Matt Austern <austern@apple.com> writes:

[...]

| So we knew all of that a year ago.  I think we know two more things now.
|   1. Other compilers implement this extension too.  I didn't know that.
|   2. It's possible to tame this extension, to permit
| assignment-to-cast while still not treating casts as lvalue for the
| purpose of overload resolution.
| 
| What #1 suggests to me is that immediate removal was more unfriendly
| than we'd thought, and what #2 suggests is that immediate removal
| wasn't the only option.  We can fix the overload resolution bug, keep
| the feature for the cases where people are likely to have used it,
| deprecate it in 4.0, and remove it in a later major release.

#1 is a circularity.

#2 makes me even more concerned.  Because, for overload resolution
purposes, we usually select overloads based on type of the
arguments.  We do not do overload resolution based on inner syntactic
structures of the arguments -- there are very few exceptions like when
we encounter a null pointer constant in form of an integer constant
with value 0 (but until recently we even failed there). Keeping that
stuff in and trying to squeeze the overload resolution process code
means that we're creating more opportunities to shoot ourselves in the
legs, much louder.  

For C++, it was given data that while Sun compiler accepts a limited
form in C, it rejects it in C++.  If C people are happy with that
stuff, it is OK with me.  But, for C++, it just needs to go.

-- Gaby

Re: generalized lvalues -- patch outline

[Joe Buck]

On Thu, Nov 25, 2004 at 01:06:42PM -0800, Matt Austern wrote:
[ cast-as-lvalue extension ]
> I changed my mind, and reluctantly agreed that immediate removal was 
> the best option, because of what Joe Buck pointed out: that this wasn't 
> a pure extension, but that it actually changed the meaning of legal C++ 
> programs by causing them to select the wrong overload in some cases.  
> This was a serious bug. Seen in that light, removal seemed like the 
> only possible answer: obviously we have to fix bugs.

There is another possible answer if it is decided that some limited form
of cast-as-lvalue must be kept (presumably under the control of some
option, or maybe just for Objective-C++): casts can be considered to be
non-lvalues for the purpose of overload resolution, unless there is no
match (at which point it can be considered an lvalue so that the
appropriate operator= or operator++ can be looked up).  This would turn
the extension back into a pure extension, at the cost of kludging up the
front end.

Re: generalized lvalues -- patch outline

[Matt Austern]

On Nov 29, 2004, at 9:59 AM, Joe Buck wrote:

> On Thu, Nov 25, 2004 at 01:06:42PM -0800, Matt Austern wrote:
> [ cast-as-lvalue extension ]
>> I changed my mind, and reluctantly agreed that immediate removal was
>> the best option, because of what Joe Buck pointed out: that this 
>> wasn't
>> a pure extension, but that it actually changed the meaning of legal 
>> C++
>> programs by causing them to select the wrong overload in some cases.
>> This was a serious bug. Seen in that light, removal seemed like the
>> only possible answer: obviously we have to fix bugs.
>
> There is another possible answer if it is decided that some limited 
> form
> of cast-as-lvalue must be kept (presumably under the control of some
> option, or maybe just for Objective-C++): casts can be considered to be
> non-lvalues for the purpose of overload resolution, unless there is no
> match (at which point it can be considered an lvalue so that the
> appropriate operator= or operator++ can be looked up).  This would turn
> the extension back into a pure extension, at the cost of kludging up 
> the
> front end.

That's the sort of thing that I'd recommend, at least for 4.0.  I think 
there
are probably other things we can do for ObjC; my main concern here is
removing a feature without giving users adequate notice.  Lots of users
will end up going directly from a compiler where this feature is fully
documented and supported to one where it's gone, without passing
through the usual intermediate stages of deprecation.

			--Matt

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

| Write down the textual amendments to C99+TC1+TC2 and C++03 which would 
| introduce your feature.  Examine *every* reference to "lvalue" in either 
| of those standards and explain how your changes interact with that 
| reference.  That's a *minimum* of analysis that would be needed for this.

I reiterate my opposing to this cast-as-lvalue abomination.  

At any rate, he should explain why and how that abomination is
different from or equal to the semantics of reinterpret_cast<>.
Furthermore, he should articulate clearly how that abomination
interacts with the semantics of "old-style" casts -- which are defined
in C++ in terms of the "new-style" casts.

| People don't need to have read the standards to be aware that casts aren't 
| lvalues; for example, having read K&R would suffice.  I don't think we 
| should accept random junk just because someone who hasn't familiarised 
| themselves with the language might throw it at the compiler: we should 
| inform them of the problem with their code and thereby help them to learn 
| the languages better.

100% agreed.

-- Gaby

Re: generalized lvalues -- patch outline

[Nathan Sidwell]

Ziemowit Laski wrote:

> By "inducing a type conversion", I meant generating code to make the 
> conversion happen, as in '(float)intValue'.  Perhaps I should have said 
> 'non-trivial type conversion' or some such.  In C, conversions among 
> pointer types should always be trivial, but in C++, conversion operators 
> could kick in.  In those non-trivial cases, we would disallow the lvalue 
> cast.

Ok, so whether this extension is applicable is implementation defined,
based on the sizes of the supported data types.  C and C++ standards
do not currently have such conditionally defined behaviour (although there
are moves to define such a term in C++ at least).

>>>   - The lvalue cast is being assigned to, incremented or decremented;
>>
>> ... or modified.  What is the bitrepresentation of the lvalue?  Is it
>> that of the newly specified type, or is the static type of the location?
> 
> 
> Since we're talking about pointers, the bit representation does not 
> change.

This is an implementation assumption.  Some machines have different
bit representations for char * and int * pointers for instance (do
we support them, I don't know).  So, this is another implementation
restriction.

>  Microsoft also allows lvalue casts so long as the type being 
> cast to is not larger than the original type (e.g., '(short)longValue' 
> is OK whereas '(long)shortValue' is not); in those cases, I'm fairly 
> certain
> we want the bit layout of the newly specified type.

so (short)longValue should not touch longValue's bits outside of a
short?  But I thought you were restricting to casts between object pointer
types, so why is this relevent?

>>>   - The lvalue is of a pointer type, and is being cast to a pointer 
>>> type.
>>
>> ok, so this answers my questions about point 1. Any pointer type? Like
>> the disallowed func->object conversion in C++? What about references
>> and/or references to pointer types?  Does array/function->pointer
>> decay occur? It might make sense to restrict the original lvalue
>> type to 'void *'.
> 
> 
> Just plain C pointers ('foo *', 'bar *'); no references and no 
> pointers-to-members, although I see no reason why we should disallow 
> arrays and function pointers.

so '(foo *)ary' is permitted?

>> Are there any restrictions on the original lvalue that is being cast?

> I don't understand this question -- what kind of restrictions could/should
> there be?

I don't know.  you tell me, you're the one specifying this extension

> 
>> Is this extension composable? For instance what about the following,
>>     #define MAGIC_REGISTER ((void *)p)
>>     (int *)MAGIC_REGISTER += 2
>>
>> What about
>>     (expr, (int *)p) = something
>> in C++?  In C++ operator, is an lvalue if its second operand is an
>> lvalue. Similarly for ?:
> 
> 
> I think the examples you give here should all work.
do you mean that these examples must be accepted by the extension?
AFAICT the first one (int *)(void *)p does not as currently specified,
because (void *)p is not an lvalue cast as it's not being assigned to
or modified. If these are to be accepted, something is lacking in the
specification.

>> Have you thought about specifying this in terms of a rewriting rule?
> 
> 
> Under the conditions specified above,
> 
>          (foo)bar
> 
> could be rewritten to
> 
>          *((foo *)&bar)

this rewriting rule falls foul of the type based aliasing rules.

>> Do you have an analysis of interaction with existing features?
> 
> 
> I don't, although I'm not sure what would constitute "analysis" in this 
> context.

Well, consider all the existing language features and show how they are
either unaffected, or the changes are not detrimental.

> I suppose you can take the rewrite rule above and then try to see if the 
> rewritten expression
> would play nicely as an rvalue in other contexts; off the top of my 
> head, I can't think of
> situations where it would not, though I welcome others to poke holes in 
> this theory.

I showed your rewriting rules break existing optimizations (or other
ways around, existing optimizations will cause your rewriting rule to
generate code that does not do what your extension claims to do). I find
'off the top of my head' to be an unsatisfactory way of defining language
extensions.

> One important thing to note is that the extension I'm proposing does not 
> change existing, valid behavior; it only affects cases that currently 
> (with TOT gcc 4.0) produce hard errors.
> 
>>  What
>> programming errors would fall into this?
> 
> 
> Are you asking, "how are programmers likely to misconstrue what this 
> extension does"?

I am asking what currently rejected programs that *really* are
programming errors, would silently be accepted, and then lead to hard
to debug problems.

> I think most programmers out there would probably be 
> surprised that this is an extension at all, since most would expect 
> something like
> 
>    (foo)bar = value;
> 
> to simply "work" :-); so probably the biggest pitfall would be that, 
> even with the extension enabled, programmers will still get non-lvalue 
> errors sometimes and then wonder why.

I beg to differ.  I have no data on what 'most' C programmers think about
bits of code that are not specified in the C standard, or any book
that teaches standard C or in the gcc documentation.  How have you
determined what 'most' programmers think about this?

>> Why do you want this extension?
>> I see 6 different possible rationales. Are they all applicable?
> 
> 
> Yes, they are all applicable, although any one of them taken separately 
> is sufficient justification, IMO. 



> MS cnd CW compatibility is important 
> because of code that is being brought over, but I don't think we 
> necessarily have to implement each corner case of this extension as 
> supported by these (and other) compilers (we could, but that would go 
> way beyond what we are proposing here).

What code is being brought over?  If compatibility is important, what
are the specifications of MS's and CW's extensions.  It appears this
information is being gathered.  It would be useless to implement a
partial extension, if the main use in the ported code was a different
bit of the extension.


>  Rather, what we are concerned 
> with is how the extensions tend to be used in real code.  And most 
> existing usage, both in Apple's case and in examples cited by Michael 
> Matz, has to do with pointer type manipulation.

 From this I understand that the use in Apple's code is accidental, as
you've not shown the coding guidelines.

You've not followed up on the ObjC rationale.  Is that an issue or
not?

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Nathan Sidwell <nathan@codesourcery.com> writes:

| Ziemowit Laski wrote:
| > Indeed, I now appear to have a mainline mod for C and C++ which
| > allows assignment to lvalue casts for pointer types.  What follows
| > is a high-level synopsis of what I did; if there is interest, I can
| > whip up a full-fledged patch, complete with docs.  Please let me
| > know.
| 
| Please describe the semantics *in detail* of what you are trying to
| achieve.  Why are the modify-assignment operators not allowed? That
| appears non-orthogonal.

We do not need that abomination.  The standard definition already
provides the semantics: reinterpret_cast.

-- Gaby

Re: generalized lvalues -- patch outline

[Kai Henningsen]

gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 23.11.04 in <m3wtwdmnwi.fsf@uniton.integrable-solutions.net>:

> We do not need that abomination.

(repeated ad nauseam)

What we really need is to stop resorting to purely emotional arguments.

MfG Kai

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

| gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 23.11.04 in <m3wtwdmnwi.fsf@uniton.integrable-solutions.net>:
| 
| > We do not need that abomination.
| 
| (repeated ad nauseam)
| 
| What we really need is to stop resorting to purely emotional arguments.

I meant abomination.  It is not emotional.
Maybe you really need to change your emotionalmeter.

-- Gaby

Re: generalized lvalues -- patch outline

[Zack Weinberg]

Gabriel Dos Reis <gdr@integrable-solutions.net> writes:

> kaih@khms.westfalen.de (Kai Henningsen) writes:
>
> | gdr@integrable-solutions.net (Gabriel Dos Reis)  wrote on 23.11.04 in <m3wtwdmnwi.fsf@uniton.integrable-solutions.net>:
> | 
> | > We do not need that abomination.
> | 
> | (repeated ad nauseam)
> | 
> | What we really need is to stop resorting to purely emotional arguments.
>
> I meant abomination.  It is not emotional.
> Maybe you really need to change your emotionalmeter.

Maybe we should avoid describing compiler (mis)features in the same
terms that God Almighty uses to express His opinion of sacrificing
infants to Moloch.  Whether or not we are making emotional judgements.

Also, as a general principle it is only necessary to say something
once.

zw

Re: generalized lvalues -- patch outline

[Richard Henderson]

On Mon, Nov 22, 2004 at 12:39:31PM -0800, Ziemowit Laski wrote:
> Indeed, I now appear to have a mainline mod for C and C++ which allows 
> assignment to lvalue casts for pointer types.  What follows is a 
> high-level synopsis of what I did; if there is interest, I can whip up 
> a full-fledged patch, complete with docs.  Please let me know.

I do not wish to have this as an extension at all.


r~

Re: generalized lvalues -- patch outline

[Gabriel Dos Reis]

Richard Henderson <rth@redhat.com> writes:

| On Mon, Nov 22, 2004 at 12:39:31PM -0800, Ziemowit Laski wrote:
| > Indeed, I now appear to have a mainline mod for C and C++ which allows 
| > assignment to lvalue casts for pointer types.  What follows is a 
| > high-level synopsis of what I did; if there is interest, I can whip up 
| > a full-fledged patch, complete with docs.  Please let me know.
| 
| I do not wish to have this as an extension at all.

Strongly seconded.  Furthermore, it is written reinterpret_cast in C++.

-- Gaby

Re: generalized lvalues -- patch outline

[Jonathan Lennox]

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 763 bytes --]

Ziemowit Laski writes:

> Indeed, I now appear to have a mainline mod for C and C++ which allows 
> assignment to lvalue casts for pointer types.  What follows is a 
> high-level synopsis of what I did; if there is interest, I can whip up 
> a full-fledged patch, complete with docs.  Please let me know.

It occurs to me -- can't "lvalue casts" be done in standard GNU C and C++?
Source code changes would be required, but they can probably be done largely
mechanically.

Here are the examples I've got -- they can maybe be cleaned up a bit, but
both of these compile your test cases -Wall-cleanly with GCC 3.4.  (They
take advantage of the GCC extension that type-punning through a union is
defined behavior.)

First, the C++ example, since it's cleaner code:


[-- Attachment #2: Type: text/plain, Size: 732 bytes --]

/* lvalue_cast<> code by Jonathan Lennox <lennox at cs dot columbia dot edu>,
 * placed in the public domain. */

template<class Targ, class Src>
Targ& lvalue_cast(Src& s)
{
  union { Src * s; Targ * t; } u;

  u.s = &s;

  return *u.t; /* GNU Extension */
}


/* Test case by Ziemowit Laski <zlaski at apple dot com> */

#include <stdlib.h>
#define CHECK_IF(expr) if (!(expr)) abort ()

static int global;

void f(int &) { global = 35; }
void f(const int &) { global = 78; }

long long_arr[2];

int main(void) {

 char *p;

 lvalue_cast<long *>(p) = long_arr;
 lvalue_cast<long *>(p)++;
 *(long *)p = -1;
 *p = -2;
 CHECK_IF(p[-1] == 0 && p[0] == -2 && p[1] == -1);

 long x = 0;
 f((int)x);
 CHECK_IF(global == 78);

 return 0;
}

[-- Attachment #3: message body text --]
[-- Type: text/plain, Size: 26 bytes --]


And then the C example:


[-- Attachment #4: Type: text/plain, Size: 662 bytes --]

/* LVALUE_CAST code by Jonathan Lennox <lennox at cs dot columbia dot edu>,
 * placed in the public domain. */

#define LVALUE_CAST(TYPE, OBJ) (*({ \
    union { __typeof__(OBJ) * s; TYPE * t; } u; \
\
    u.s = &OBJ; \
    u.t; /* GNU Extension */\
}))


/* Test case by Ziemowit Laski <zlaski at apple dot com> */

#include <stdlib.h>
#define CHECK_IF(expr) if (!(expr)) abort ()

int main(void) {

 char *p;
 long l;
 short s;

 LVALUE_CAST(long *, p) = &l; /* ok */
 LVALUE_CAST(long *, p)++; /* ok */
 LVALUE_CAST(short, l) = 2; /* Result depends on endianness. */
 LVALUE_CAST(long, s) = 3;  /* Stack clobber; run-time undefined behavior. */

 return 0;
}

[-- Attachment #5: message body and .signature --]
[-- Type: text/plain, Size: 232 bytes --]


You'd have to do a global replace of lvalue casts with the new construct,
but I imagine that's a lot easier to explain to programmers than the strict
details of the new rules.

-- 
Jonathan Lennox
lennox at cs dot columbia dot edu

Re: generalized lvalues

[Joseph S. Myers]

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)

Re: generalized lvalues

[Alex Rosenberg]

On Nov 18, 2004, at 10:19 AM, Mike Stump wrote:

> Just a random data point, 58 out of 1252 (4.6%) projects failed to 
> build because of it.

Then there are some 50-odd programmers at Apple that need to be taught 
a coding standard.

+------------------------------------------------------------+
| Alexander M. Rosenberg           <mailto:alexr@_spies.com> |
| Nobody cares what I say. Remove the underscore to mail me. |

Re: generalized lvalues

[Matt Austern]

On Nov 17, 2004, at 7:50 PM, Andrew Pinski wrote:

>
> On Nov 17, 2004, at 10:47 PM, Matt Austern wrote:
>
>>  1. It broke valid C++ programs.  If we overload a function on 
>> constness, like foo(int&) and foo(const int&), then invoking it as 
>> foo((int) x) is required to call the const version.  Generalized 
>> lvalues made us choose the latter.
>
> If it broke it please file a bug and don't complain that we broke it.

No, no!  Other way around.  The fact that we used to have generalized 
lvalues broke valid C++ programs, and getting rid of generalized 
lvalues fixed that class of bugs.  That's one of the reasons we got rid 
of them.

That's what I was trying to say, anyway.  I was trying to list all the 
reasons I knew of why we got rid of generalized lvalues.  I was not 
trying to list reasons for bringing them back.  My apologies if I was 
unclear.

			--Matt

Re: generalized lvalues

[Dale Johannesen]

On Nov 17, 2004, at 7:47 PM, Matt Austern wrote:
>  3. I have the vague sense that it caused back end bugs, but I can't 
> find them offhand.

I don't recall any, but it could easily have interacted badly with the 
strict aliasing checks.

Re: generalized lvalues

[Fariborz Jahanian]

What was the rational to have this extension in the first place. Maybe 
we sould dig this out before
declaring that it was a 'bad idea'.

- fariborz

On Nov 17, 2004, at 7:47 PM, Matt Austern wrote:

> Could somebody remind me, please, of the reasons we removed 
> generalized lvalues?  I know there were several reasons, but I'm not 
> sure if I've ever seen a complete list.  Here are the reasons I can 
> reconstruct from memory:
>  1. It broke valid C++ programs.  If we overload a function on 
> constness, like foo(int&) and foo(const int&), then invoking it as 
> foo((int) x) is required to call the const version.  Generalized 
> lvalues made us choose the latter.
>  2. It was underspecified. There were cases, again especially in C++ 
> in the presence of operator overloading, where nobody was quite sure 
> either what it did or what it was supposed to do.
>  3. I have the vague sense that it caused back end bugs, but I can't 
> find them offhand.
>
> Anything else?  (Incidentally, I think all of these apply to 
> cast-as-lvalue.  I haven't heard of any problems caused by 
> conditional-as-lvalue or comma-expression-as-lvalue.)
>
> The reason I'm asking: I think some people are going to find the 
> removal a nasty surprise.  Yes, it was deprecated in 3.3.x and 3.4.x, 
> but not everyone upgrades to the latest release of older branches. I 
> imagine some people won't have noticed the discussion about removal 
> until they upgrade to 4.0 and see that it's gone.  At that point we'll 
> have three choices: convince them that removing it made the compiler 
> better, or reconsider and put it back, or refuse to put it back, don't 
> tell anyone why it's gone, and live with unhappy users who think we're 
> stupid and capricious.  If we want to go with one of the first two 
> options, it'll help to have a collection of reasons.
>
> 			--Matt
>

Re: generalized lvalues

[Joe Buck]

On Thu, Nov 18, 2004 at 08:18:50AM -0800, Fariborz Jahanian wrote:
> What was the rational to have this extension in the first place. Maybe 
> we sould dig this out before
> declaring that it was a 'bad idea'.

It's a C extension that is wrong for C++.

It interacts very badly with overloading.  There is no overloading in C.
 

Re: generalized lvalues

[Ziemowit Laski]

On 18 Nov 2004, at 10.09, Joe Buck wrote:

> On Thu, Nov 18, 2004 at 08:18:50AM -0800, Fariborz Jahanian wrote:
>> What was the rational to have this extension in the first place. Maybe
>> we sould dig this out before
>> declaring that it was a 'bad idea'.
>
> It's a C extension that is wrong for C++.
>
> It interacts very badly with overloading.  There is no overloading in 
> C.

Of course, since we are discussing a language extension, _we_ get to 
decide how it interacts with C++ overloading.
For the same reason, Matt's assertion that the feature "breaks valid 
C++ programs" is inherently contradictory,
since programs containing it cannot be valid. :-)

--Zem

Re: generalized lvalues

[Steven Bosscher]

On Friday 19 November 2004 01:14, Ziemowit Laski wrote:
> For the same reason, Matt's assertion that the feature "breaks valid
> C++ programs" is inherently contradictory,
> since programs containing it cannot be valid. :-)

If you're in a discussion you should read what others say ;-)

http://gcc.gnu.org/ml/gcc/2004-11/msg00609.html
http://gcc.gnu.org/ml/gcc/2004-11/msg00607.html

Gr.
Steven


 
 
 
 

Re: generalized lvalues

[Joe Buck]

On Thu, Nov 18, 2004 at 04:14:21PM -0800, Ziemowit Laski wrote:
> Of course, since we are discussing a language extension, _we_ get to 
> decide how it interacts with C++ overloading.
> For the same reason, Matt's assertion that the feature "breaks valid 
> C++ programs" is inherently contradictory,
> since programs containing it cannot be valid. :-)

You just completely ignored what I wrote.  Go back and read it again.
Cast-as-lvalue breaks valid C++ programs.  Period.  It breaks programs
that never assign to a cast.

Re: generalized lvalues

[Ziemowit Laski]

On 18 Nov 2004, at 16.40, Joe Buck wrote:

> On Thu, Nov 18, 2004 at 04:14:21PM -0800, Ziemowit Laski wrote:
>> Of course, since we are discussing a language extension, _we_ get to
>> decide how it interacts with C++ overloading.
>> For the same reason, Matt's assertion that the feature "breaks valid
>> C++ programs" is inherently contradictory,
>> since programs containing it cannot be valid. :-)
>
> You just completely ignored what I wrote.  Go back and read it again.
> Cast-as-lvalue breaks valid C++ programs.  Period.  It breaks programs
> that never assign to a cast.

You're right -- for some reason, I completely blanked out on the fact 
that the cast is still legal (!!!), and so that we're (more or less 
silently) changing the semantics of that cast.  My apologies...

Also, I realized that the lvalue casts that I desire would never be 
used in the scenario your example depicts; I'm really concerned about 
"assigning to a cast", as you put it.

--Zem

Re: generalized lvalues

[Ziemowit Laski]

Just to give a little background: the reason for Matt's (and Apple's) 
renewed interest in being able to cast lvalues (so that they retain 
their lvalueness) is that we realized (somewhat belatedly, I admit) 
that removing this feature may cause problems for us.  The first 
problem is one of legacy code with lvalue casts, which I'm sure all of 
us share to some degree regardless of target platform.

The second problem has to do with emerging garbage collection (GC) 
support in ObjC/ObjC++ (which, of course, we hope to offer back to the 
FSF once the design gets baked in, though it is not ready for prime 
time just yet).  It turns out that lvalue casts are extremely useful in 
this context, e.g.:

     void *objPtr;
       :
     (__strong id)objPtr = someOtherObj;

Since objPtr is a plain-vanilla 'void *', it is not in general subject 
to the new NeXT runtime GC regime.  However, if we happen to assign a 
pointer to an ObjC instance to it, then we do want to give a hint to 
the compiler that objPtr _should_ be tracked by GC.  The most 
straighforward -- and intuitive -- way of doing this is precisely via a 
cast applied to the lvalue, as seen above (with '__strong' expanding to 
an appropriate attribute).  While we have investigated some syntactic 
alternatives to the cast in light of the impending lvalue cast removal, 
all of them are counterintuitive in that they fail to express what is 
being done -- namely, altering the type of a variable for a particular 
assignment.  (The GC-enabled compiler will look at the type of the lhs 
to decide whether to emit a write-barrier call.)

So, at least as far as Apple is concerned, it would be great if the 
casts-as-lvalues functionality were retained in GCC. :-)  Of course, if 
the compiler is run in -strict/-pedantic/-ansi/whatever mode, it should 
be free to reject this construct if it is not in the appropriate 
standard.  It's just that there are C/C++ usage idioms out there (as 
non-standard as they may be) for which the lvalue cast is a better 
semantic fit than any alternative.

I'll attempt to address the various technical reasons for removing 
lvalue casts in a separate e-mail.  For the time being, though, I just 
wanted to express a partisan viewpoint on the issue. :-)

Thanks,

--Zem
--------------------------------------------------------------
Ziemowit Laski                 1 Infinite Loop, MS 301-2K
Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: generalized lvalues

[Matt Austern]

On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote:

> Since objPtr is a plain-vanilla 'void *', it is not in general subject 
> to the new NeXT runtime GC regime.  However, if we happen to assign a 
> pointer to an ObjC instance to it, then we do want to give a hint to 
> the compiler that objPtr _should_ be tracked by GC.  The most 
> straighforward -- and intuitive -- way of doing this is precisely via 
> a cast applied to the lvalue, as seen above (with '__strong' expanding 
> to an appropriate attribute).  While we have investigated some 
> syntactic alternatives to the cast in light of the impending lvalue 
> cast removal, all of them are counterintuitive in that they fail to 
> express what is being done -- namely, altering the type of a variable 
> for a particular assignment.

Just a reminder: the word "impending" isn't quite right.  It's not that 
cast-as-lvalue isn't going away, but that it's already gone.  It won't 
come back unless someone does the work to put it back, including 
documentation, testing, and integration with the 4.0 back end.

Yes, if we discover that removing it caused major problems then we 
might be forced to consider doing that work.  But we'd better be aware 
that at this point you aren't proposing that we avoid doing something, 
you're proposing a project to add functionality that isn't here.

			--Matt

Re: generalized lvalues

[Zack Weinberg]

Matt Austern <austern@apple.com> writes:

> On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote:
>> The most straighforward -- and intuitive -- way of doing this is
>> precisely via a cast applied to the lvalue, as seen above (with
>> '__strong' expanding to an appropriate attribute).  While we have
>> investigated some syntactic alternatives to the cast in light of
>> the impending lvalue cast removal, all of them are counterintuitive
>> in that they fail to express what is being done -- namely, altering
>> the type of a variable for a particular assignment.

I would like to point out that in *my* arrogant opinion, this use of
lvalue casts is completely *un*intuitive; I would prefer either
declaring the void * with the "this is a GC root" attribute in the
first place, e.g.

   id object;
   void *__gcroot ptr;
   ...
   ptr = object;

or (if for some reason that is impossible) a builtin function call,
e.g.

   id object;
   void *ptr;
   ...
   __builtin_gc_register(ptr);
   ptr = object;

> Just a reminder: the word "impending" isn't quite right.  It's not that 
> cast-as-lvalue isn't going away, but that it's already gone.  It won't 
> come back unless someone does the work to put it back, including 
> documentation, testing, and integration with the 4.0 back end.

Not only that, but unless someone brought a *very* compelling argument
to the table, we wouldn't even consider it for 4.0 - the time for
adding features to 4.0 was six months ago.

zw

Re: generalized lvalues

[Ziemowit Laski]

On 18 Nov 2004, at 15.44, Zack Weinberg wrote:

> Matt Austern <austern@apple.com> writes:
>
>> On Nov 18, 2004, at 3:28 PM, Ziemowit Laski wrote:
>>> The most straighforward -- and intuitive -- way of doing this is
>>> precisely via a cast applied to the lvalue, as seen above (with
>>> '__strong' expanding to an appropriate attribute).  While we have
>>> investigated some syntactic alternatives to the cast in light of
>>> the impending lvalue cast removal, all of them are counterintuitive
>>> in that they fail to express what is being done -- namely, altering
>>> the type of a variable for a particular assignment.
>
> I would like to point out that in *my* arrogant opinion, this use of
> lvalue casts is completely *un*intuitive; I would prefer either
> declaring the void * with the "this is a GC root" attribute in the
> first place, e.g.
>
>    id object;
>    void *__gcroot ptr;
>    ...
>    ptr = object;
>
> or (if for some reason that is impossible) a builtin function call,
> e.g.
>
>    id object;
>    void *ptr;
>    ...
>    __builtin_gc_register(ptr);
>    ptr = object;

Thing is, the code in AppKit and Foundation (our ObjC frameworks) 
routinely
juggles large swaths of uninitialized (and "untyped") memory which is 
then
gradually used up to hold various things, only some of which are 
pointers
to GC-able objects.  So statically typing 'ptr' in such cases is out of
the question.  Of course, in other cases, what you suggest _is_ possible
and we do it already:

     __strong void *ptr;
        :
     ptr = object;    /* write-barrier call will be generated. */

(Note the consistent way in which '__strong' is used.)

The __builtin_gc_register approach would require that the entire GC API
be redesigned, and of course would be extremely inefficient, since 
_every_
assignment in a program would have to go through a write-barrier which 
would
either do something or nothing depending on whether 
__builtin_gc_register and/or
__builtin_gc_unregister has been called.

The "cleanest" syntactic approach we could come up with so far is

   __builtin_objc_gc_strong(ptr) = object;

which I suppose we can live with, though the lhs doesn't look too 
lvaluish this way... :-(

--Zem

Re: generalized lvalues

[Zack Weinberg]

Ziemowit Laski <zlaski@apple.com> writes:

> The __builtin_gc_register approach would require that the entire GC
> API be redesigned, and of course would be extremely inefficient, since
> _every_ assignment in a program would have to go through a
> write-barrier which would either do something or nothing depending on
> whether __builtin_gc_register and/or __builtin_gc_unregister has been
> called.

I think you misunderstood what I meant it to mean - it was intended to
be a suggestion for alternative notation producing *exactly the same
code generation* as your proposal.  In other words, the effect of
__builtin_gc_register would be to notify the compiler to generate
write barriers for every assignment to ptr from then until a
subsequent __builtin_gc_unregister.

>   __builtin_objc_gc_strong(ptr) = object;

How about 

__builtin_with_write_barrier (ptr = object);

?

Tangentially. I am not enthused by the implication that you (Apple)
have implemented write barriers by compiler annotation of pointer
operations.  That's not my idea of state-of-the-art GC technology.

zw

Re: generalized lvalues

[Ziemowit Laski]

On 18 Nov 2004, at 17.41, Zack Weinberg wrote:

> Ziemowit Laski <zlaski@apple.com> writes:
>
>> The __builtin_gc_register approach would require that the entire GC
>> API be redesigned, and of course would be extremely inefficient, since
>> _every_ assignment in a program would have to go through a
>> write-barrier which would either do something or nothing depending on
>> whether __builtin_gc_register and/or __builtin_gc_unregister has been
>> called.
>
> I think you misunderstood what I meant it to mean - it was intended to
> be a suggestion for alternative notation producing *exactly the same
> code generation* as your proposal.  In other words, the effect of
> __builtin_gc_register would be to notify the compiler to generate
> write barriers for every assignment to ptr from then until a
> subsequent __builtin_gc_unregister.

Oh, OK.  I read __builtin_gc_register like a regular statement
(i.e., affected by control-flow), whereas you're giving it a more 
#pragma-like flavor.
>

>>   __builtin_objc_gc_strong(ptr) = object;
>
> How about
>
> __builtin_with_write_barrier (ptr = object);

Actually, a secret admirer gave me an off-list suggestion for

    __builtin_with_write_barrier(ptr, object);

which ain't bad. :-)  Note that I do need to hand both 'ptr' and 
'object' (and not just the
result of the assignment) to the write-barrier.

> Tangentially. I am not enthused by the implication that you (Apple)
> have implemented write barriers by compiler annotation of pointer
> operations.  That's not my idea of state-of-the-art GC technology.

I'm no GC maven, and so can't really argue that one with you.  I will 
say, though, that
the objective here was to introduce GC into Objective-C in a way that 
was binary compatible
with legacy ObjC programs running against the new runtime.  So our 
theoretical playing field
was not very large here.  In a way, this is very similar to our 
_setjmp()/_longjmp()-based
EH in ObjC and why we could not use the DWARF EH approach.

Actually, I'm not sure what you mean by "compiler annotation of pointer 
operations" --
the write-barriers (of which there are several flavors!) are all 
implemented as API calls into
the runtime.

--Zem

Re: generalized lvalues

[Zack Weinberg]

Ziemowit Laski <zlaski@apple.com> writes:

>> How about
>> __builtin_with_write_barrier (ptr = object);
>
> Actually, a secret admirer gave me an off-list suggestion for
>
>    __builtin_with_write_barrier(ptr, object);
>
> which ain't bad. :-)

Yeah, I'd be fine with that.

> Note that I do need to hand both 'ptr' and 'object' (and not just
> the result of the assignment) to the write-barrier.

In my proposal, you could hook into the parser and get the MODIFY_EXPR
instead of the result of assignment.  Think Lisp special form.  (For
an existing example, look at the implementation of __builtin_va_arg.)

> Actually, I'm not sure what you mean by "compiler annotation of
> pointer operations" -- the write-barriers (of which there are
> several flavors!) are all implemented as API calls into the runtime.

Any GC write-barrier implemented by having the compiler synthesize
extra code for pointer operations - API calls, open-coded manipulation
of GC structures, whatever - qualifies as "annotation of pointer
operations."  The intended contrast is with a write barrier that
doesn't affect the generated code, e.g. one implemented by having the
operating system write-protect old generations.

> I'm no GC maven, and so can't really argue that one with you.  I will
> say, though, that the objective here was to introduce GC into
> Objective-C in a way that was binary compatible with legacy ObjC
> programs running against the new runtime.  So our theoretical playing
> field was not very large here.  In a way, this is very similar to our
> _setjmp()/_longjmp()-based EH in ObjC and why we could not use the
> DWARF EH approach.

Fair enough.  I do understand this sort of constraint.

zw

Re: generalized lvalues

[Nathan Sidwell]

Ziemowit Laski wrote:

> The "cleanest" syntactic approach we could come up with so far is
> 
>   __builtin_objc_gc_strong(ptr) = object;
> 
> which I suppose we can live with, though the lhs doesn't look too 
> lvaluish this way... :-(

It looks more lvaluish than '(cast)ptr = object'.  Functions can
return references (in C++), so one could actually write such a function.
The same is not true of the cast notation.

void *&__builtin_objc_gc_strong(void *&p) {return p;}

Do you need a solution that works in both C and C++?

If you're adding language extensions, you should choose one that is the
smallest possible extension (ideally, it would be 'not-an-extension').
The cast-as-lvalue idea fails for C++, as Joe Buck has pointed out, and
it fails for C as it makes a whole swathe of ill-formed uses now well-formed,
but with non-intuitive semantics.  For instance does '(short)int_var = something'
write only the 'short' bits of int_var, or the whole thing?  What
does '(int)short_var = something' mean?  What does '&(short)int_var' give you?
Is it endian-dependent?  Sure, meanings could be defined, but ISTM that
there's a whole rat's nest of strange corner conditions ready trip up
programmers and compilers.

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: generalized lvalues

[Ziemowit Laski]

On 19 Nov 2004, at 4.38, Nathan Sidwell wrote:

>
> Do you need a solution that works in both C and C++?

Yes.
>
> If you're adding language extensions, you should choose one that is the
> smallest possible extension (ideally, it would be 'not-an-extension').
> The cast-as-lvalue idea fails for C++, as Joe Buck has pointed out, and
> it fails for C as it makes a whole swathe of ill-formed uses now 
> well-formed,
> but with non-intuitive semantics.

Yes, Joe raised a very good point, although it made me realize that I'm 
not really
after the whole casts-as-lvalues enchilada, but really after the 
ability to be
assign to a cast.  I believe the compiler will currently complain about 
assigning
to a non-lvalue, and what I'd need is some sort of -fassign-to-cast 
flag (off by default,
but on for ObjC/ObjC++) that would let it go through.  Of course, the 
compiler should only
allow the assignment if the cast does _not_ result in a temporary being 
created.

--Zem

Re: generalized lvalues

[Andrew Pinski]

On Nov 18, 2004, at 6:28 PM, Ziemowit Laski wrote:
>     void *objPtr;
>       :
>     (__strong id)objPtr = someOtherObj;

That syntax wants me to puke.

Just use the correct type at the beginning and not do tricks like
this.

-- Pinski

Re: generalized lvalues

[Joe Buck]

On Thu, Nov 18, 2004 at 03:28:15PM -0800, Ziemowit Laski wrote:
> So, at least as far as Apple is concerned, it would be great if the 
> casts-as-lvalues functionality were retained in GCC. :-)  Of course, if 
> the compiler is run in -strict/-pedantic/-ansi/whatever mode, it should 
> be free to reject this construct if it is not in the appropriate 
> standard.  It's just that there are C/C++ usage idioms out there (as 
> non-standard as they may be) for which the lvalue cast is a better 
> semantic fit than any alternative.

The main reason why cast-as-lvalue is bad news for C++ is its effect
on overloading.  Consider:

void func(const Type&);
void func(Type&);

...

	func((Type)expression);

cast-as-lvalue causes the wrong overloaded function to be called.
The user would expect the cast to produce a temporary, meaning that
the const version is called; however, because of the extension, the
non-const version is called.  This is not a small matter; given a
non-const reference we can normally be sure that we have a real object
of the given type, that we can write that object, save its address, etc.
With a non-const reference, it might be bound to a temporary.

Notice that in the above example, the programmer had no idea that his
or her code was affected by an extension.  There are two versions of
func and the compiler chooses the wrong one.  We shouldn't require
-ansi or -pedantic to make correct code work correctly; in the past,
we just use them to reject more incorrect code.

If you must retain this extension, then at minimum we would need to
prevent cast-as-lvalue from modifying the type of the cast expression
for the purposes of overloading; even though it's an lvalue for the
purpose of assignment, it can't be treated as an lvalue for purposes
of operator overloading.  That might be tricky.


 
> I'll attempt to address the various technical reasons for removing 
> lvalue casts in a separate e-mail.  For the time being, though, I just 
> wanted to express a partisan viewpoint on the issue. :-)
> 
> Thanks,
> 
> --Zem
> --------------------------------------------------------------
> Ziemowit Laski                 1 Infinite Loop, MS 301-2K
> Mac OS X Compiler Group        Cupertino, CA USA  95014-2083
> Apple Computer, Inc.           +1.408.974.6229  Fax .5477

Re: generalized lvalues

[Aaron W. LaFramboise]

As a user, while I know its a little too late to be concerned, this
concerns me in that some of the code I may be interested in compiling
with GCC may use this extension.  The maintainers of this code may be
unwilling to 'fix' it, and hearing that it breaks GCC may be reason for
them to leave it broken perpetually.

So, from a political perspective, this may not be a good thing, as some
proprietary software developers who are vaguely hostile towards GNU may
use this change in GCC as a way to further lock out non-proprietary
compilers.

I sympathize with the notion that extensions to the standard should be
approached conservatively and with much care.  But what about the case
where that extension is widely used and all comparable compilers support
it?  Are there any widely-used C compilers out that that _don't_
implement the pointer case of this extension?

Aaron W. LaFramboise