------- Comment #21 from rguenther at suse dot de 2006-05-17 15:06 -------
Subject: Re: [4.1/4.2 regression] VRP miscompilation
of simple loop
On Wed, 17 May 2006, rakdver at gcc dot gnu dot org wrote:
>
>
> ------- Comment #14 from rakdver at gcc dot gnu dot org 2006-05-17 13:40
> -------
> (In reply to comment #12)
> > Ok, the patch fixes this PR, but not PR26719.
> >
> > Index: tree-chrec.c
> > ===================================================================
> > --- tree-chrec.c (revision 113852)
> > +++ tree-chrec.c (working copy)
> > @@ -1150,7 +1150,7 @@ chrec_convert (tree type, tree chrec, tr
> > 1, 2, ..., 127, -128, ... The result should not be
> > {(schar)1, +, (schar)1}_x, but instead, we should keep the
> > conversion: (schar) {(uchar)1, +, (uchar)1}_x. */
> > - if (scev_probably_wraps_p (type, base, step, at_stmt, loop,
> > + if (scev_probably_wraps_p (ct, base, step, at_stmt, loop,
> > &dummy, &dummy))
> > goto failed_to_convert;
> >
> >
>
> although I think the idea of the fix is OK, you must be more careful --
> scev_probably_wraps_p does computations with base and step in type,
> so you cannot just pass another type to it.
Currently we do that - base, step are of type ct (chrec_type (chrec)),
while we pass type, which is signed(!) char here. I.e.
scev_probably_wraps_p computes completely bogus values - the canonical
type is ct, not type (I guess this was just a typo).
> The problem with fold_convert is that currently it is a patch over patch; it
> checks for overflows twice (once using scev_probably_wraps_p and once again
> in convert_step_widening), but neither of the checks is exactly what is
> needed.
> I recall having this fixed once (perhaps on killloop branch), I will check
> whether I can find the patch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27639
