Re: Possible problem wiht nonoverlapping_component_refs_p

[Richard Henderson <rth at redhat dot com>]

On Thu, Dec 06, 2001 at 06:12:39AM -0500, Richard Kenner wrote:
> 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.

C considers this undefined in the "strict aliasing" paragraph, 6.5/7.

GCC explicitly allows type punning through unions.  This promise 
can be seen in the documentation for -fstrict-aliasing.

>     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.

Err, we _should_ be able to compute the field's offset within the 
union, since we have all of the intermediate fields.

> 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.

Hmm.  Perhaps we're talking about the same thing.

> One question is what to do about fields at variable positions.

Ug.  I had no idea we had to worry about that.  I guess we have
to give up if that's accessed from a union, but otherwise we 
should be able to handle it.


r~