This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch, scev] Fix PR tree-optimization/36630
- From: Ira Rosen <IRAR at il dot ibm dot com>
- To: "Daniel Berlin" <dberlin at dberlin dot org>
- Cc: gcc-patches at gcc dot gnu dot org, sebpop at gmail dot com, rakdver at kam dot mff dot cuni dot cz
- Date: Mon, 28 Jul 2008 10:59:15 +0300
- Subject: Re: [patch, scev] Fix PR tree-optimization/36630
"Daniel Berlin" <dberlin@dberlin.org> wrote on 17/07/2008 15:06:13:
> On Thu, Jul 17, 2008 at 4:25 AM, Ira Rosen <IRAR@il.ibm.com> wrote:
> >
> > Hi,
> >
> > The test in PR36630 ICEs, since evolution_part_in_loop_num returns NULL
for
> > the access function (short int) {(short unsigned int) i_44, +, 1}_1).
> > Adding STRIP_NOPS before chrec's analysis solves the problem.
>
> How did the access function get a cast in front of it in the first place?
>
> My admittedly possibly out of date recollection is that casts can only
> occur inside the chrec.
The cast was there before the vectorization as well:
(set_scalar_evolution
(scalar = i_13)
(scalar_evolution = (short int) {3, +, 1}_1))
)
> Sure sure, but the real question is "it is valid to have a chrec with
> a cast in front of it".
Maybe Sebastian or Zdenek could clear it up?
>
> If so, then *all* the functions that extract data from chrecs need to
> be modified approriately to handle it, not just the one you've
> modified below.
>
Thanks,
Ira