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

Mark Mitchell <> 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.

I understand your point. But I think this is getting more and more unlikely:
the offset is highly dependent on target, ABI, optimization settings,
compiler version and whatnot, and without offsetof() there is no
(real-world) way to know it. Moreover, incorrect uses of offsetof() are
diagnosed by G++ (by default).

> We have to choose ourselves.

My humble opinion is that we could turn TBAA on (with these POD
restrictions) for C++ whatever the language lawyers decide on the issue, and
I wouldn't expect to ever see a bug report for miscompilation about it. For
C++ POD types and C language, there are probably too many unclear issues to
turn TBAA on by default.
Giovanni Bajo

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