Richard Guenther <richard.guenther <at> gmail.com> writes:
> On Wed, Jan 6, 2010 at 7:20 PM, Nick Stoughton <nick <at> msbit.com>
wrote:
> > The C1x timetable has us finishing the draft for an initial ballot this
> > summer (the April Florence meeting being the last chance to submit new
> > material). The best expert I know on the type based aliasing stuff is
> > Clark Nelson at Intel (clark.nelson <at> intel.com). We did spend a
> > considerable amount of time at the recent Santa Cruz meeting discussing
> > this subject ... see N1409 and N1422 (the minutes including a summary of
> > the discussion on N1409).
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1409.htm
> >
> > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1422.pdf
> [...]
> I have no idea on how to raise this issue with the std body, somebody
> else might and can pass on the above example please.
In the notes that Nick referenced it says:
Is there anybody that thinks the rules are clear enough? No one is
really able to interpret them. So it seems that they are not
clear enough. The problem is how to state them.
[...]
ACTION: Clark to work on a clearer formulation of what the rules are,
re: N1409.
So it wounds like Clark is already working on this. We should just write
to him and point him to this thread. I can do this.
With regard to a clearer way to state the rules: I think the rules would
be easier to understand if the normative part only addressed the ways in
which object aliases could be *created*. For example, the rules could
state that:
struct A { int x; } a;
int *pi = &a.x;
...is a valid way to create an int* that aliases a struct member, whereas:
int i;
struct A { int x; } *a = (struct u*)&i;
...is not. Then an informative section could address the consequences of
those rules with respect to the assumptions you can make when optimizing
a function in isolation:
type3 x;
void foo(type1 *a, type2 *b) {
// can a and b alias each other? can either of them alias x?
}
The root of my confusion at least was thinking that the standard was
describing legal ways aliases could be created, but it was actually
describing what aliases could come to exist through other processes.
Since the rules governing how aliases may be created are simpler, it
makes sense to me to have the normative rules about alising describe the
creation of aliases, and then let compilers implement whatever
optimizations they can dream up that still respect those rules.
I also think the aliasing rules should more directly address the issue
raised in DR#236:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_236.htm
Josh
