This is the mail archive of the
mailing list for the GCC project.
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: dan at cgsoftware dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 3 Dec 01 08:26:07 EST
- Subject: 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.