Possible problem wiht nonoverlapping_component_refs_p

[Richard Kenner]

    Hmm, that does appear broken.  I'd convinced myself that the language
    didn't allow two live objects to overlap.  Technically, the language
    doesn't.  But unions are one place that GCC has promised that this sort
    of thing would work.

    Now, we did only promise that this would work when accessed directly
    through the union,

I'm confused.  What does this "promise" refer to?  I didn't realize that C
considers this undefined, but I can see why it might.

    so we don't have to worry about

	struct T1 *t1_1 = &u.t2.x;
	struct T1 *t1_2 = &u.t2.y;
	t1_1->b vs t1_2->a

That was indeed the case I was the most concerned about.

    So if we do have offset data all the way up the chain (which we
    should), then we should be able to handle this as with your
    overlapping fields, no?

Actually, I don't think we do have offset data all the way up, but I don't
think we need it for this.  We don't have the intermediate offset data
because we never form a MEM for it, looking directly as far as we can in
get_inner_reference.  The only offsets that are meaningful are from the decl
and from the expression.  So the overlap check for the intermediate fields
would have to be conservative and see if the fields themselves overlap.
However, that's only slightly more conservative and I think fine.

One question is what to do about fields at variable positions. On the
one hand, access to such fields is likely to be so ineffecient that
optimizing this case may not seem worth, but on the other hand, it's indeed
true that such fields cannot overlap in any language I know of, so it's
safe and we might as well help such as much as we can.  I'm leaning towards
the latter view at the moment.