skaller writes:
> 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.
The claim was, in the context of the example given, "Without strict
aliasing being enabled, the compiler can't assume that that the assignment
'p[i] = 1' won't change 'p'". If you do enable GCC's strict type-based
aliasing analysis, then GCC will assume that the assignment can't change
"p" and generate better code.
Another way to put the "strict alias" rule is that two memory references
can't refer to an overlapping region of memory if the types being
referenced are different, with the exception of certain combinations of
types or in certain cases in a union. For cases where the "strict alias"
rule doesn't apply, either because of the types involved or because its
disabled, "non-strict" alias analysis can find other cases whether two
memory references can't overlap. For example, it's obvious that the
assigment of one variable to another (eg. "a = b") can't overlap because
all variables are allocated unique non-overlapping regions of memory.
A reference to an automatic variable can't overlap any reference to
memory through a pointer, if that automatic variable hasn't had its
address taken. (Note how in my example, "p" has its address taken and
passed to another function so this rule doesn't apply.)
Note the use of the word "reference" in the above paragraph means
any operation that causes memory to be accessed whether by reading or
writing it. It doesn't mean only the use of C++ reference type.
Ross Ridge
