This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 27 May 2013 09:01:28 +0000
- Subject: [Bug tree-optimization/57343] [4.8/4.9 Regression] wrong code on x86_64-linux at -Os and above
- Auto-submitted: auto-generated
- References: <bug-57343-4 at http dot gcc dot gnu dot org/bugzilla/>
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)))
{