From patchwork Fri Jul 2 11:14:11 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Biener X-Patchwork-Id: 57649 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E6F65B6F10 for ; Fri, 2 Jul 2010 21:14:24 +1000 (EST) Received: (qmail 3898 invoked by alias); 2 Jul 2010 11:14:21 -0000 Received: (qmail 3879 invoked by uid 22791); 2 Jul 2010 11:14:19 -0000 X-SWARE-Spam-Status: No, hits=-3.4 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from cantor2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 02 Jul 2010 11:14:13 +0000 Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.221.2]) by mx2.suse.de (Postfix) with ESMTP id 5AF2D8F54B for ; Fri, 2 Jul 2010 13:14:11 +0200 (CEST) Date: Fri, 2 Jul 2010 13:14:11 +0200 (CEST) From: Richard Guenther To: gcc-patches@gcc.gnu.org Subject: [PATCH] Fix prefetching ICE on i?85 for eon Message-ID: User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org This fixes an ICE in data-dependence computation which doesn't expect data-references like MEM[(double &)&p + 32] = D.2212_95; ... p[0][j_7][0] = D.2168; do appear. This can now happen with mem-ref, and I believe could happen already before with whole array-assignments in the IL. The easiest solution is to punt here (note that MEM[(double &)&p + 32] is accessing a part of p[0][1][0]). Bootstrap and regtest running on x86_64-unknown-linux-gnu, will apply if that succeeds. Richard. 2010-07-02 Richard Guenther * tree-data-ref.c (initialize_data_dependence_relation): Handle mismatching number of dimensions properly. * g++.dg/torture/20100702-1.C: New testcase. Index: gcc/tree-data-ref.c =================================================================== *** gcc/tree-data-ref.c (revision 161701) --- gcc/tree-data-ref.c (working copy) *************** initialize_data_dependence_relation (str *** 1452,1458 **** return res; } ! gcc_assert (DR_NUM_DIMENSIONS (a) == DR_NUM_DIMENSIONS (b)); DDR_AFFINE_P (res) = true; DDR_ARE_DEPENDENT (res) = NULL_TREE; --- 1452,1465 ---- return res; } ! /* If the number of dimensions of the access to not agree we can have ! a pointer access to a component of the array element type and an ! array access while the base-objects are still the same. Punt. */ ! if (DR_NUM_DIMENSIONS (a) != DR_NUM_DIMENSIONS (b)) ! { ! DDR_ARE_DEPENDENT (res) = chrec_dont_know; ! return res; ! } DDR_AFFINE_P (res) = true; DDR_ARE_DEPENDENT (res) = NULL_TREE; Index: gcc/testsuite/g++.dg/torture/20100702-1.C =================================================================== --- gcc/testsuite/g++.dg/torture/20100702-1.C (revision 0) +++ gcc/testsuite/g++.dg/torture/20100702-1.C (revision 0) @@ -0,0 +1,37 @@ +// { dg-do compile } +// { dg-options "-fprefetch-loop-arrays -w" } + +class ggPoint3 { +public: + ggPoint3(); + inline double &x() { + return e[0]; + } + inline double &y() { + return e[1]; + } + ggPoint3(const ggPoint3 &p); + double e[3]; +}; +class ggBox3 { +public: + ggPoint3 min() const; +}; +class ggHAffineMatrix3; +ggPoint3 operator*(const ggHAffineMatrix3 &m, const ggPoint3 &v); +void foo (ggPoint3 *); +void SetMatrix(ggHAffineMatrix3& toworld, ggBox3& box) +{ + ggPoint3 p[2][2][2]; + int i, j, k; + for (i = 0; i < 2; j++) + for (k = 0; k < 2; k++) + { + if (i == 0) + p[i][j][k].x() = box.min().x(); + if (j == 0) + p[i][j][k].y() = box.min().y(); + p[i][j][k] = toworld * p[i][j][k]; + } + foo (&p[0][0][0]); +}