http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #8) > On Fri, 24 May 2013, rakdver at gcc dot gnu.org wrote: > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343 > > > > --- Comment #7 from Zdenek Dvorak <rakdver at gcc dot gnu.org> --- > > (In reply to Richard Biener from comment #4) > > > We then fall to > > > > > > if (multiple_of_p (TREE_TYPE (c), c, s)) > > > { > > > /* If C is an exact multiple of S, then its value will be reached > > > before > > > the induction variable overflows (unless the loop is exited in > > > some > > > other way before). Note that the actual induction variable in > > > the > > > loop (which ranges from base to final instead of from 0 to C) may > > > overflow, in which case BNDS.up will not be giving a correct > > > upper > > > bound on C; thus, BNDS_U_VALID had to be computed in advance. */ > > > no_overflow = true; > > > exit_must_be_taken = true; > > > > > > which ends up with no_overflow = true and things going downhill from here. > > > > This is the problem -- multiple_of_p claims that (var * 100) is a multiple > > of > > 100, which is not the case if the multiplication overflows. I am not sure > > whether this is an expected behavior of multiple_of_p, or whether this could > > cause problems in its other uses. > > > > A conservative fix here would be to replace the multiple_of_p test here by > > some > > safer tests -- important special cases are: > > 1) both c and s are constants and c is a multiple of s > > 2) s = 1 > > Thanks. I'll audit other uses of multiple_of_p to see whether the > current behavior is desired or a bug. Most uses are ok, the extract_muldiv_1 use is questionable. I'll fixup the use in niter analysis like the following: - if (multiple_of_p (TREE_TYPE (c), c, s)) + if (integer_onep (s) + || (TREE_CODE (c) == INTEGER_CST + && TREE_CODE (s) == INTEGER_CST + && tree_to_double_int (c).mod (tree_to_double_int (s), + TYPE_UNSIGNED (type), + EXACT_DIV_EXPR).is_zero ()) + || (TYPE_OVERFLOW_UNDEFINED (TREE_TYPE (c)) + && multiple_of_p (type, c, s))) {