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

On Mon, 3 Dec 2001, Richard Kenner wrote:

>     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.
That's not what i'm saying.
I'm saying that if these things are supposed to allow the representation
of such things (to use your terminology), and what you are trying to use
them for is significantly different, then this is bad.
Surely, having fields that overlap is a significant difference than a
collection of fields?

> 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
> property.
> 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.

Where exactly is *this* documented?
How could one possibly write code that works properly on trees if it
>  A RECORD_TYPE is simply a collection of fields.
That don't overlap.
> 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.
Then wouldn't it be best to enable one to say either "the fields in this
struct can overlap" or to use a new tree type that isn't quite a union,
isn't quite a record?

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