On Tue, 12 Jan 2016, Tom de Vries wrote:
> On 12/01/16 14:04, Richard Biener wrote:
> > On Tue, 12 Jan 2016, Tom de Vries wrote:
> >
> > > On 12/01/16 12:22, Richard Biener wrote:
> > > > Doesnt' the same issue apply to
> > > >
> > > > > > unsigned int *p;
> > > > > >
> > > > > > static void __attribute__((noinline, noclone))
> > > > > > foo (void)
> > > > > > {
> > > > > > unsigned int z;
> > > > > >
> > > > > > for (z = 0; z < N; ++z)
> > > > > > ++(*p);
> > > > > > }
> > > > thus when we have a MEM_REF[p_1]? SCEV will not analyze
> > > > its evolution to a POLYNOMIAL_CHREC and thus access_fns will
> > > > be NULL again.
> > > >
> > >
> > > I didn't manage to trigger this scenario, though I could probably make it
> > > happen by modifying ftree-loop-im to work in one case (the load of the
> > > value
> > > of p) but not the other (the *p load and store).
> > >
> > > > I think avoiding a NULL access_fns is ok but it should be done
> > > > unconditionally, not only for the DECL_P case.
> > >
> > > Ok, I'll retest and commit this patch.
> >
> > Please add a comment as well.
>
> Patch updated with comment.
>
> During testing however, I ran into two testsuite regressions:
>
> 1.
>
> -PASS: gfortran.dg/graphite/pr39516.f -O (test for excess errors)
> +FAIL: gfortran.dg/graphite/pr39516.f -O (internal compiler error)
> +FAIL: gfortran.dg/graphite/pr39516.f -O (test for excess errors)
>
> AFAIU, this is a duplicate of PR68976.
>
> Should I wait with committing the patch until PR68976 is fixed?
Yes - we shouldn't introduce new testsuite regressions willingly at this
point.
> 2.
>
> -XFAIL: gcc.dg/graphite/scop-pr66980.c scan-tree-dump-times graphite "number
> of SCoPs: 1" 1
> +XPASS: gcc.dg/graphite/scop-pr66980.c scan-tree-dump-times graphite "number
> of SCoPs: 1" 1
>
> AFAIU, this is not a real regression, but the testcase needs to be updated.
> I'm not sure how. Sebastian, perhaps you have an idea there?
It looks like simply removing the xfail might be ok. But the comment in
the testcase doesn't suggest its dependency analysis fault that the
situation is not handled so I'd like Sebastian to chime in (who also
should know the dependence code very well).
Thanks,
Richard.
