[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above

[rguenther at suse dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57343

--- Comment #8 from rguenther at suse dot de <rguenther at suse dot de> ---
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.