From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5622 invoked by alias); 13 Jan 2016 08:42:59 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 5610 invoked by uid 89); 13 Jan 2016 08:42:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:2283 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 13 Jan 2016 08:42:58 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:41931) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1aJH16-0000lA-31 for gcc-patches@gnu.org; Wed, 13 Jan 2016 03:42:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aJH11-0007Ts-NL for gcc-patches@gnu.org; Wed, 13 Jan 2016 03:42:55 -0500 Received: from mx2.suse.de ([195.135.220.15]:42769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aJH11-0007Tn-G2 for gcc-patches@gnu.org; Wed, 13 Jan 2016 03:42:51 -0500 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 45D57ABE5; Wed, 13 Jan 2016 08:42:50 +0000 (UTC) Date: Wed, 13 Jan 2016 08:42:00 -0000 From: Richard Biener To: Tom de Vries cc: Sebastian Pop , "gcc-patches@gnu.org" Subject: Re: [PATCH, PR69110] Don't return NULL access_fns in dr_analyze_indices In-Reply-To: <5695436D.4000003@mentor.com> Message-ID: References: <5694CF85.1020708@mentor.com> <5694F5BA.7030207@mentor.com> <5695436D.4000003@mentor.com> User-Agent: Alpine 2.11 (LSU 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x (no timestamps) [generic] X-Received-From: 195.135.220.15 X-SW-Source: 2016-01/txt/msg00801.txt.bz2 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.