From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 39335 invoked by alias); 23 Dec 2015 18:30:28 -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 39280 invoked by uid 89); 23 Dec 2015 18:30:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=ubizjakgmailcom, ubizjak@gmail.com, richard.guenther@gmail.com, richardguenthergmailcom X-HELO: mail-wm0-f43.google.com Received: from mail-wm0-f43.google.com (HELO mail-wm0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 23 Dec 2015 18:30:22 +0000 Received: by mail-wm0-f43.google.com with SMTP id l126so158017088wml.0 for ; Wed, 23 Dec 2015 10:30:21 -0800 (PST) X-Received: by 10.28.23.136 with SMTP id 130mr38083767wmx.94.1450895419219; Wed, 23 Dec 2015 10:30:19 -0800 (PST) Received: from android-4c5a376a18c0e957.fritz.box (p548F2D96.dip0.t-ipconnect.de. [84.143.45.150]) by smtp.gmail.com with ESMTPSA id l7sm38498452wjx.14.2015.12.23.10.30.18 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 23 Dec 2015 10:30:18 -0800 (PST) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Subject: Re: [PATCH, middle-end]: Fix PR68999, gfortran.fortran-torture/execute/save_1.f90 execution failure on alpha From: Richard Biener Date: Wed, 23 Dec 2015 18:30:00 -0000 To: Uros Bizjak CC: "gcc-patches@gcc.gnu.org" ,Jeff Law ,Jan Hubicka Message-ID: X-IsSubscribed: yes X-SW-Source: 2015-12/txt/msg02101.txt.bz2 On December 23, 2015 5:58:07 PM GMT+01:00, Uros Bizjak wrote: >On Wed, Dec 23, 2015 at 2:39 PM, Richard Biener > wrote: >> On December 23, 2015 10:39:17 AM GMT+01:00, Uros Bizjak > wrote: >>>Hello! >>> >>>There is a logic error in Honza's patch "Transparent alias suport >part >>>10" [1]. The part in memrefs_conflict_p should be changed to: >>> >>>- /* If decls are different or we know by offsets that there is >no >>>overlap, >>>- we win. */ >>>- if (!cmp || !offset_overlap_p (c, xsize, ysize)) >>>+ /* If decls are different and we know by offsets that >>>+ there is no overlap, we win. */ >>>+ if (!cmp && !offset_overlap_p (c, xsize, ysize)) >>> return 0; >>>- /* Decls may or may not be different and offsets overlap....*/ >>>+ /* Decls are different and offsets overlap....*/ >>> >>>Even if decls are different, their offsets shouldn't overlap! >> >> Comparing offsets of different decls does not make sense. > >Uh, yes, some more eyeballing was needed, but you are right. > >Is there a way to detect aliasing in case AND addresses are involved? > >Probably we need something like in base_alias_check, where: Yeah, and in that case just give up. Richard. >--cut here-- >/* The base addresses are different expressions. If they are not >accessed > via AND, there is no conflict. We can bring knowledge of object > alignment into play here. For example, on alpha, "char a, b;" can > alias one another, though "char a; long b;" cannot. AND addesses may > implicitly alias surrounding objects; i.e. unaligned access in DImode > via AND address can alias all surrounding object types except those > with aligment 8 or higher. */ > if (GET_CODE (x) == AND && GET_CODE (y) == AND) > return 1; > if (GET_CODE (x) == AND > && (!CONST_INT_P (XEXP (x, 1)) > || (int) GET_MODE_UNIT_SIZE (y_mode) < -INTVAL (XEXP (x, 1)))) > return 1; > if (GET_CODE (y) == AND > && (!CONST_INT_P (XEXP (y, 1)) > || (int) GET_MODE_UNIT_SIZE (x_mode) < -INTVAL (XEXP (y, 1)))) > return 1; >--cut here- > >Uros.