This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
- From: "dberlin at dberlin dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 26 Jul 2005 18:41:21 -0000
- Subject: [Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev
- References: <20050629203622.22236.pinskia@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From dberlin at gcc dot gnu dot org 2005-07-26 18:41 -------
Subject: Re: [4.1 Regression] wrong code for
casts and scev
On Tue, 2005-07-26 at 17:19 +0200, Sebastian Pop wrote:
> Dorit Naishlos wrote:
> >
> > The modifications you suggest will make the tests uninteresting - they were
> > introduced with unknown loop-bound/offset on purpose. In fact, for most of
> > these tests there are already versions with explicit constant values for
> > the loop-bound/offset -
>
> Okay, I won't modify any of these testcases.
>
> > vect-46.c with explicit loop-bound becomes vect-40.c
> > vect-50.c with explicit loop-bound becomes vect-44.c
> > vect-52.c with explicit loop-bound becomes vect-48.c
> > vect-58.c with explicit loop-bound becomes vect-54.c
> > vect-60.c with explicit loop-bound becomes vect-56.c
> > vect-77.c and vect-78.c with explicit offset become vect-75.c
> > and vect-92.c also uses unknown loop-bound on purpose.
> >
> > Can we change something else in the tests to make the evolution-analyzer
> > return something saner? by changing types of variables? by using some flag?
> >
>
> I don't think it is possible to properly convert these ivs without
> knowing an approximation of the number of iterations.
I disagree.
They are int.
Nothing modifies the upper bound in the loop.
The upper bound is also int.
They are not casted back and forth to unsigned.
The only definition of the induction variable is in the bumper statement
(i = i + 1).
This should be more than sufficient to prove it does not wrap, and that
we can convert it.
--Dan
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22236