This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
- From: "rakdver at kam dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 25 Feb 2009 22:41:08 -0000
- Subject: [Bug middle-end/39297] [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
- References: <bug-39297-682@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #12 from rakdver at kam dot mff dot cuni dot cz 2009-02-25 22:41 -------
Subject: Re: [4.4 Regression] gcc.dg/tree-ssa/loop-31.c
> ------- Comment #11 from hjl dot tools at gmail dot com 2009-02-25 19:18 -------
> (In reply to comment #10)
> > The difference between
> >
> > > D.1254 = &a[0] + ((long unsigned int) ((unsigned int) len + 4294967295) + 1)
> > > * 2;
> >
> > (original) and
> >
> > > D.1255 = ((long unsigned int) &a + 2) + (long unsigned int) ((unsigned int)
> > > len + 4294967295) * 2;
> >
> > (current) is mostly cosmetical; the test in the testcase should be made more
> > robust, but other than that, there is no regression here.
> >
>
> The new loop is
>
> .L3:
> st2 [r14] = r33, 2
> ;;
> cmp.ne p6, p7 = r15, r14
> (p6) br.cond.sptk .L3
>
> The old loop is
>
> mov ar.lc = r15
> .L3:
> st2 [r14] = r33, 2
> ;;
> br.cloop.sptk.few .L3
>
> They are quite different.
nevertheless, loop-31.c test is not supposed to test this; it just
checks whether strength reduction is performed correctly. I think we
already have another PR regarding the problem that strength reduction
and iv elimination on tree level may cause rtl level # of iterations
analysis to fail (which leads to the code difference).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39297