This is the mail archive of the
mailing list for the GCC project.
- From: Daniel Berlin <dan at cgsoftware dot com>
- To: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sat, 3 Nov 2001 09:19:36 -0500
- Subject: Re: alias.c:nonoverlapping_component_refs_p
On Monday, December 3, 2001, at 08:50 AM, Richard Kenner wrote:
> 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
> that fields are in increasing bit number because they are that way in C?
No, but i would expect that if it was not true, it would be documented
Not because i expect the tree codes to match C, but because Ada was only
If it changed the way things are, or valid assumptions you can make, it
should be documented that the possible semantics have changed.
> 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
> 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*.
And you've changed the assumptions without changing documentation about
what assumptions *are* true.
No front end before Ada allowed fields that overlapped.
Therefore, there needs to be something saying that record_type is now
allowed to have fields that overlap.
> If some
> assumption is not listed, you are not entitled to make it. Nowhere is
> 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
> written that assumed fields don't overlap.
However, the documentation that *does* exist implies they don't.