This is the mail archive of the gcc-patches@gcc.gnu.org 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


    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.


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