This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to rguenther@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)))
     {


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]