🚀 go-pugleaf

Thomas Wolf (wolf@lglsun.epfl.ch) wrote:
: In article <46msr4$ee9@elaine25.Stanford.EDU>, sanjoy@leland.Stanford.EDU (sanjoy ghosh) writes:
: :> Hi,
: :> 
: :> I was looking at the code generated for the following program:
: :> 
: :> struct try {
: :>         int     tr1;
: :>         int     tr2;
: :>         int     tr3;
: :>         int     tr4;
: :> };
: :> 
: :> int try1 (struct try *array, int *index)
: :> {
: :>         int     i;
: :> 
: :>         for (i = 0; i < 10; i++)
: :>         {
: :>                 array[index[i]].tr3 = i;
: :>                 array[index[i]].tr2 = i + 10;
: :>                 array[index[i]].tr1 = i + 20;
: :>         }
: :> }
: :> 
: :> 
: :> Most compilers assume that index and array could be aliased and reload index[i]
: :> for each of the 3 indexes into array in the loop body.  So they load index[i]
<snip>
: But 'index' might point to one of the fields within the struct 'try', so it
: might be modified by the assignments within the loop.

But a very clever compiler (don't ask me to write it) could spot that index[0]
through index[10] is used so 'index' cannot legitimatly point to one of the
fields in struct 'try'. If it did then you would have undefined behaviour.
Another posibility is that 'index' and 'array' are different members within 
the same union - but that still means you have undefined behaviour.
I can't think of any case where they can be aliasis and not trip over
undefined behaviour.

--
Stephen Baynes                              baynes@mulsoc2.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom