skaller <[EMAIL PROTECTED]> writes:
> On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> > skaller <[EMAIL PROTECTED]> writes:
> >
> > > On Mon, 2007-11-05 at 14:30 -0500, Ross Ridge wrote:
> > >
> > > > One example of where it hurts on just about any platform is something
> > > > like this:
> > > >
> > > > void allocate(int **p, unsigned len);
> > > >
> > > > int *foo(unsigned len) {
> > > > int *p;
> > > > unsigned i;
> > > > allocate(&p, len);
> > > > for (i = 0; i < len; i++)
> > > > p[i] = 1;
> > > > return p;
> > > > }
>
> > The assignment is indeed of an int, but it uses a pointer. Strict
> > aliasing only refers to loads and stores which use pointers. The
> > type-based alias analysis is done on the types to which those pointers
> > point.
> >
> > Given two pointers, "T1* p1" and "T2* p2", type based alias analysis
> > (aka strict aliasing) lets us conclude that p1 and p2 point to
> > different memory if T1 and T2 are incompatible types with respect to
> > aliasing. The rules for alias compatibility come straight from the C
> > standard.
>
> Yes but I still don't understand. The claim was that the assignment
> might modify p. This is is contra-indicated since p is a pointer
> to an int, whereas the value being assigned is an int.
Right. That is type based aliasing that tells you that.
> In particular, let me try to build a model: partition all the
> types into classes which can alias each other, in two ways:
> with strict aliasing (S), and with rough aliasing (R).
I recommend that you just read the standard and see the real aliasing
rules.
> However this is a different circumstance. My understanding
> was that gcc with strict aliasing turned off would optimise
> the code above the same way as if it were on. On amd64
> an int cannot alias a pointer (int is 32 bits, pointer is
> 64 bits).
What, other than strict aliasing, tells you that the two types can not
be aliased? It is perfectly possible to do a 32-bit write to half of
a 64-bit value.
Ian
