> > Well, what are our rules for whether overflow on POINTER_PLUS_EXPR is
> > defined or not? A quick search through the headers and docs doesn't turn
> > up anything. Would there be a downside to defining it as wrapping?
> > 
> > Can you show an example where a POINTER_PLUS_EXPR produced by ivopts
> > would overflow?
> Don't have a testcase right now, I've just seen IVOPTS many times in the
> past initialize an IV with start of array minus some constant, end of array
> plus some constant or similar (which is fine if the IV is unsigned integer
> of the size of a pointer, but certainly wouldn't be fine if the IV had
> pointer type).  For pointer arithmetics in the IL we assume the C
> requirements, pointer arithmetics can be performed only within the same
> object, so for
> int a[10];
> both of the following are invalid, even in the IL:
> int *p = a - 1;
> int *q = a + 11;

for example, something like this:

int a[1000];

void foo(int n)
  int i, *p = a;

  for (i = 8; i < n; i++)
    *p++ = 10;

ivopts may decide to change this to:

int a[1000];

void foo(int n)
  int i, *p = a - 8;

  for (i = 8; i < n; i++)
    p[i] = 10;

which may require one less adition, depending on the available addressing modes.
Of course, as written above this has undefined behavior; hence, the casts to
unsigned integer,


Reply via email to