This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH]: Fix PR tree-optimization/21407

Mike Stump wrote:
On May 10, 2005, at 8:51 PM, Daniel Berlin wrote:
However, since I can't see it as in any way useful

I'd like to think google ("upcast") or google ("up-cast") could convince you...

Generally frowned upon, but handy some of the time. Maybe C needs an up_cast() operator? :-) Given that, and requiring it, would allow the optimizer to do what it does best, almost all the time, and the 2 lines per million that need up_cast, could use it.

Also, it would seem to me that Ada and Java probably have upcast, and that the back end has to work for them too... I just don't know if they would trip over it.
At least for java, there is a lot of structure that keep things easy to understand. For one the upcasting is allowed specificly in the context of the class heirarchy. This is different from just taking any field that happens to be in a record and recovering a reference to the record. With respect to the gcc implementation, or analysis always assumed that if you had a pointer to field, you also had a pointer to every kind of object you could get by chaining thru the TYPE_BINFO structure. The question that we had was if you had a pointer to a field, did you also have to assume you had a pointer to every other field in the structure and every structure that that structure could be inbedded into?

I wonder, Mike, do you make any distinction between a c program that upcasts on the first field of a record and one that uses the offsetof operator to upcast from the middle of a record?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]