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 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 
> 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 
recently introduced.
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 
> 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*.

And you've changed the assumptions without changing documentation about 
what assumptions *are* true.
No front end before Ada allowed fields that overlapped.
Ada does.
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 
> 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.
However, the documentation that *does* exist implies they don't.


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