[Bug tree-optimization/22236] [4.1 Regression] wrong code for casts and scev

dberlin at dberlin dot org gcc-bugzilla@gcc.gnu.org
Tue Jul 26 18:52:00 GMT 2005


------- 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



More information about the Gcc-bugs mailing list