This is the mail archive of the
mailing list for the GCC project.
Re: Possible problem wiht nonoverlapping_component_refs_p
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- To: rth at redhat dot com
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 6 Dec 01 06:12:39 EST
- Subject: Re: Possible problem wiht nonoverlapping_component_refs_p
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.