This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
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?
kenny