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:50:21 EST
- Subject: Re: alias.c:nonoverlapping_component_refs_p
Surely, having fields that overlap is a significant difference than a
collection of fields?
No, it's a subset. There are *lots* of properties such a list of fields can
have that are true for C but are not to be implied for all RECORD_TYPEs. For
example, would you also conclude that there's an assumption in RECORD_TYPEs
that fields are in increasing bit number because they are that way in C?
Look at the ARRAY_TYPE example again.
> 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.
Where exactly is *this* documented? How could one possibly write code
that works properly on trees if it isn't?
Where is *what* documented? You don't write documention by listing a set of
assumptions that are *not* true, you list those that *are*. If some
assumption is not listed, you are not entitled to make it. Nowhere is it
stated that field positions don't overlap or that they are monotonically
increasing, for that matter.
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?
One could, but I don't think it would add much. Until now, no code has been
written that assumed fields don't overlap.