This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix reset_evolution_in_loop bug
- From: Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Henderson <rth at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Mon, 6 Jun 2005 18:52:37 +0200
- Subject: Re: [PATCH] Fix reset_evolution_in_loop bug
- References: <20050407073841.GA23707@napoca.cri.ensmp.fr> <20050407092105.GO17420@devserv.devel.redhat.com> <20050408103643.GA6053@napoca.cri.ensmp.fr> <20050408225909.GF11261@redhat.com> <20050411082846.GA4967@napoca.cri.ensmp.fr> <20050420190952.GC4545@redhat.com> <20050606120921.GA5474@napoca.cri.ensmp.fr> <20050606154911.GS22349@devserv.devel.redhat.com>
Jakub Jelinek wrote:
> On Mon, Jun 06, 2005 at 02:09:21PM +0200, Sebastian Pop wrote:
> > I installed the following patch in the gcc-4_0-branch after a
> > bootstrap and regtest on i686.
> >
> > @@ -717,7 +724,7 @@ reset_evolution_in_loop (unsigned loop_n
> > {
> > if (TREE_CODE (chrec) == POLYNOMIAL_CHREC
> > && CHREC_VARIABLE (chrec) > loop_num)
> > - return build
> > + return build2
> > (TREE_CODE (chrec),
> > build_int_cst (NULL_TREE, CHREC_VARIABLE (chrec)),
> > reset_evolution_in_loop (loop_num, CHREC_LEFT (chrec), new_evol),
>
> While looking at a (whitespace caused) merge conflict, I have noticed
> that this really can't be right.
>
> POLYNOMIAL_CHREC is 3 operand tree, so using build2 to create
> it (and creating it with INTEGER_CST TREE_TYPE) IMHO must have never worked
> realy well.
>
> Here is (so far untested) patch. Ok for HEAD/4.0 if testing succeeds?
>
yes, thanks for catching it.