On 10/18/2013 02:10 PM, Richard Biener wrote: > 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.
Okay, my patch doesn't address that part, it only ensures the pointer base values are kept and arithmetic on them is done using POINTER_PLUS. The original patch was here. http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01104.html Bernd
