Re: Aliasing brokenness (Was: Re: [patch RFC] SH: Use FRAME_GROWS_DOWNWARD)

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Ian Lance Taylor <ian@airs.com> writes:

| Mark Mitchell <mark@codesourcery.com> writes:
| 
| > >>>That's the rule we've tried to use in GCC, as well; that if "p" and
| > >>>"q" pointer to distinct types (not part of the same alias set) then
| > >>>modifying "*p" cannot change the value of "*q", unless both accesses
| > >>>are directly through a union.  I don't know that the front ends and
| > >>>optimizers are careful about preserving the user's access through
| > >>>unions, but they could in theory be appropriately careful.
| > >
| > > That is, I think 6.5.2.3 is an explicit statement of a restricted form
| > > of the rule you describe in the first paragraph.  It does not go
| > > beyond what you described already.
| > 
| > How do you read the "visibility" language?  The idea that the
| > visibility of the union is all that is required seemed to imply a
| > stronger statement to me.
| 
| I'm sorry, you're right.  I thought I understood, but I did not.  The
| effect is that if you have any pointer to a struct which appears in a
| union, you may have a pointer to the initial parts of any other struct
| in the union.  Which is what you said.  Sorry for the noise.

Is the conclusion that a presence of "potentially unused" union that
contains two structures with the same prefix destroys non-aliasing
assumptions?

-- Gaby