From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32245 invoked by alias); 28 Feb 2012 14:33:43 -0000 Received: (qmail 32232 invoked by uid 22791); 28 Feb 2012 14:33:41 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Feb 2012 14:33:28 +0000 From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/52406] [4.7 Regression] likely wrong code bug Date: Tue, 28 Feb 2012 14:37:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Blocks Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-02/txt/msg02702.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52406 Richard Guenther changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |50067 --- Comment #6 from Richard Guenther 2012-02-28 14:32:58 UTC --- The issue is that we want to disambiguate a[i].f1 and a[i].f2, so for the "base object" we zero out all known indices, resulting in a[0].f1 and a[0].f2 which we then disambiguate (and conclude that for all i there cannot be a dependence). Now, when we mix pointer accesses with array accesses most of the index analysis falls apart (which is what the fix for PR50067 tries to make work more reliably - see its comment #13 on the dr_may_alias_p issue ...) So, it's really wrong to try to fixup DR_BASE_OBJECT to make dr_may_alias_p work, and it is equally wrong to use DR_BASE_OBJECT in dr_may_alias_p. Using DR_REF (a safe bet) falls foul of failing a load of testcases, for example gcc.dg/vect/pr37027.c which is no longer vectorized because (compute_affine_dependence stmt_a: D.1722_7 = a[i_24].f1; stmt_b: D.1725_11 = a[i_24].f2; ) -> dependence analysis failed previously we'd have used a[0].f1 and a[0].f2 in the disambiguation in dr_may_alias_p and disambiguated the accesses. We can try a similar trick as with REALPART/IMAGPART_EXPR to recover this. Add a constant access function for outer COMPONENT_REFs (those we can strip off the base object).