On Fri, Oct 18, 2013 at 2:02 PM, Bernd Schmidt <ber...@codesourcery.com> wrote: > On 10/18/2013 01:18 PM, Richard Biener wrote: > >> Index: gcc/fold-const.c >> =================================================================== >> --- gcc/fold-const.c (revision 203267) >> +++ gcc/fold-const.c (working copy) >> @@ -7270,8 +7270,8 @@ fold_plusminus_mult_expr (location_t loc, enum tre >> HOST_WIDE_INT int01, int11, tmp; >> bool swap = false; >> tree maybe_same; >> - int01 = TREE_INT_CST_LOW (arg01); >> - int11 = TREE_INT_CST_LOW (arg11); >> + int01 = int_cst_value (arg01); >> + int11 = int_cst_value (arg11); >> >> this is not correct - it will mishandle all large unsigned numbers. >> >> The real issue is that we rely on twos-complement arithmetic to work >> when operating on pointer offsets (because we convert them all to >> unsigned sizetype). That makes interpreting the offsets or expressions >> that compute offsets hard (or impossible in some cases), as you can >> see from the issues in IVOPTs. > > I still have patches to keep pointer types in ivopts (using a new > POINTER_PLUSV_EXPR). Would that help in this case? Last time I posted > them they met an unenthusiastic reception so I've never bothered to > repost them.
Can you point me to that patch? Or shortly elaborate on "keep pointer types in ivopts"? I think this issue is about decomposing offset computations into a constant and a variable part, which after foldings messed up the unsigned computation can result in "odd" constant offset parts. So it's rather because the offset operand of POINTER_PLUS_EXPR is fixed as sizetype. Richard. > > Bernd >
