This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: strict aliasing


skaller <skaller@users.sourceforge.net> writes:

> On Tue, 2007-11-06 at 00:15 -0800, Ian Lance Taylor wrote:
> > skaller <skaller@users.sourceforge.net> 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]