This is the mail archive of the gcc-patches@gcc.gnu.org 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


Giovanni Bajo wrote:
Kenneth Zadeck <zadeck@naturalbridge.com> wrote:


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.


Notice that exactly the same holds true in C++ for non-POD classes (which
usually are most of the classes in a given translation unit), because
offsetof is only allowed for POD types. Also, non-PODness is viral, which
means that if you embed a non-POD into a structure, you get a non-POD.

I don't think life is that good.


I think that the "what is an object" concerns apply in C++ too. Though you don't have "offsetof" for non-PODs, nothing says you can't just *know* the offset and use it in the exact same way. I really don't think we can language-lawyer our away arounad the issues here; there is no clear answer in the standard at this point. We have to choose ourselves.

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


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