http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46675
--- Comment #15 from Richard Guenther <rguenth at gcc dot gnu.org> 2010-11-28
15:54:57 UTC ---
(In reply to comment #14)
> Hm, no. The patch in comment #13 is not correct fix.
>
> However, the comment of bound_difference says that no overflows are assumed:
>
> /* Stores the bounds on the value of the expression X - Y in LOOP to BNDS.
> The subtraction is considered to be performed in arbitrary precision,
> without overflows.
>
> We do not attempt to be too clever regarding the value ranges of X and
> Y; most of the time, they are just integers or ssa names offsetted by
> integer. However, we try to use the information contained in the
> comparisons before the loop (usually created by loop header copying). */
>
> static void
> bound_difference (struct loop *loop, tree x, tree y, bounds *bnds)
>
> And we have an overflow here (slightly modified test):
>
> --cut here--
> #define OFFS 1
>
> extern void abort (void);
>
> int j;
>
> void
> __attribute__((noinline))
> foo (int n)
> {
> int npairs, i;
> npairs = n - (-__INT_MAX__ - OFFS);
>
> if (npairs > 0)
> for (i = 0; i < npairs; i++)
> j++;
> }
>
> int
> main ()
> {
> foo (5 - __INT_MAX__ - OFFS);
>
> if (j != 5)
> abort ();
>
> return 0;
> }
> --cut here--
>
>
> An interesting fact, the testcase is miscompiled only for OFFS={1,2,3}.
Note that for OFFS 2 and 3 you invoke undefined behavior as
-__INT_MAX__ - OFFS overflows. It doesn't for OFFS == 1 though, and there
is no overflow in the program in that case. But writing it as
n + -(-__INT_MAX__ - 1) has an overflow, the negation.
I didn't yet try to investigate the number of iterations code, but I'll have
a look tomorrow.
