https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98813
--- Comment #7 from Jiu Fu Guo <guojiufu at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > (In reply to Jiu Fu Guo from comment #0)
> > > For the below code:
> > > ---t.c----
> > > void
> > > foo (const double* __restrict__ A, const double* __restrict__ B, double*
> > > __restrict__ C,
> > > int n, int k, int m)
> > > {
> > > for (unsigned int l_m = 0; l_m < m; l_m++)
> > > C[n + l_m] += A[k + l_m] * B[k];
> > > }
> >
> > Try using unsigned long instead of unsigned int.
> > I think this is the same as PR 61247.
>
> Yes, I think we've seen plenty examples in the past where conversions in
> the SCEV chain prevent analysis.
Yes. Thanks for your comments and suggestions!
And for this code (unsigned int), I'm thinking if we really need runtime
scev/overflow checking before vectorizing it to guard `n+m<4294967295 &&
m<4294967295`.
Without this guard, I'm wondering if the optimization is correct for the code
in comment 4.
