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: alias.c:nonoverlapping_component_refs_p

    The part that says RECORD_TYPE represents a c struct or a pascal record.

I interpret that as "such as".  In other words, this node is meant to allow
representation of such things.

    If Ada's semantics are significantly different, then it shouldn't be
    using that tree code, or should be differentiable in a way that allows
    for us to simply say "Oh, it's an ada subtype of a variant record, we
    can't assume if two fields arent the same, they don't overlap".
    Because as far as I know, in C, this is a valid assumption.

There are a lot of assumptions in C that aren't true for tree nodes and I
don't think that saying that a certain tree node is used for a certain C
concept implies that *every* semantic restriction of the C object are implied
for that tree node.

For example, an ARRAY_TYPE can have an arbitrary lower bound (used for Ada
and Fortran, at least).  You certainly can't argue that this is not permitted
because ARRAY_TYPE is used to represent C arrays and C arrays don't have that

The point of tree nodes is that they are more general than the objects they
are representing in *any* language and that they have semantics as defined in
tree.def and tree.h.  A RECORD_TYPE is simply a collection of fields.

Now, you could argue that the intent of the difference between UNION_TYPE and
RECORD_TYPE is the fact that there is permitted overlap in the fomer.
However, I'd argue that the difference is that *all* fields are defined to
overlap in the former and that the latter is more general.

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