Re: alias.c:nonoverlapping_component_refs_p

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    Err.. why?  What can you do with a collapsed represenation that
    you can't do with the uncollapsed representation?  It's all 
    compiler internals after all...

It's more the other way around: there's no benefit whatsoever for the
hierarchical representation and all it does is add complexity.  If the
user has specified the position for all fields (the case we are talking
about here), the hierarchy has no significance and would have to be
peculiar in any event.  Suppose the fields were positioned in opposite
order, with the ones at the end of the variant placed last.  You'd end up
with all the intermediate types having bit positions of zero and sizes equal
to that of the whole type.  Putting those in just adds clutter (and doesn't
eliminate the problem of overlapping fields because the field containing
the QUAL_UNINT_TYPE will overlap any fields that are lexically before
the variant.)

    struct S {
      long w, x, y, z;
    };

    static inline void foo(struct S *s) { s->x = 0; }
    extern void bar(struct S *s);
    
    struct S test(void)
    {
      struct S asdf;
      foo(&asdf);
      bar(&asdf);
    }

    I'd expect this sort of example to be fairly common in C++, where
    FOO winds up being an inline member function and the passed struct
    being the object manipulated.

I see.  I don't think you need a MEM_DECL for that, though: couldn't
you just copy the MEM_EXPR value and insert the decl?

However, I wondering: perhaps it shouldn't be either MEM_DECL or MEM_EXPR
but instead a MEM_DECLLIST which is a TREE_VEC listing the decls (either
VAR_DECL or FIELD_DECL) that are passed through.