On Fri, Mar 16, 2012 at 12:20:44AM +0100, Bernd Schmidt wrote:
> On 03/16/2012 12:16 AM, Jakub Jelinek wrote:
> > On Fri, Mar 16, 2012 at 12:03:08AM +0100, Bernd Schmidt wrote:
> >> On 03/15/2012 11:12 PM, Zdenek Dvorak wrote:
> >>
> >>> the reason unsigned integer types are prefered is that possible overflows
> >>> during the computation have defined semantics.  With pointer types, the
> >>> intermediate steps of the computations could have undefined behavior, 
> >>> possibly
> >>> confusing further optimizations.  Is the patch with this regard?
> >>
> >> It's trying to use sizetype for pointer offset computations. As far as I
> >> can tell that's supposed to be an unsigned type, so it should be OK. I
> >> think the final POINTER_PLUS_EXPRs we make can't overflow in valid 
> >> programs.
> > 
> > In the IL before ivopts it shouldn't for valid programs, but what ivopts
> > makes out of it often would, that is why it uses unsigned integers instead.
> 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;


Reply via email to