From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24720 invoked by alias); 17 Jan 2013 17:05:28 -0000 Received: (qmail 24692 invoked by uid 22791); 17 Jan 2013 17:05:26 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 17 Jan 2013 17:05:18 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r0HH5DdJ008906 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Jan 2013 12:05:15 -0500 Received: from pebble.twiddle.net (vpn-55-202.rdu2.redhat.com [10.10.55.202]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r0HH54ep017474; Thu, 17 Jan 2013 12:05:08 -0500 Message-ID: <50F82F3F.5050901@redhat.com> Date: Thu, 17 Jan 2013 17:05:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alexandre Oliva CC: ubizjak@gmail.com, Aldy Hernandez , gcc-patches@gcc.gnu.org Subject: Re: [PR55547] fix alias regression on alpha on misaligned symbols References: <50F582CE.3090201@redhat.com> <50F585DB.2020706@redhat.com> <50F70571.3080606@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2013-01/txt/msg00913.txt.bz2 On 2013-01-16 18:40, Alexandre Oliva wrote: >> That said, I question the change of <= to == 0. If negative, we don't >> know how much overlap there is as far as I can see. > > Why not? Since the addresses are constants, and the negative sizes are > just the adjusted sizes, negated to indicate they were conservatively > lengthened by an alignment operation... Oh, right. >> This hunk is not needed, as we begin by eliminating <= 0. So the abs >> is certain to do nothing. > > The function I'll introduce to keep the expressions the same will have > the abs and I'll use it here, but you're right that after testing for > negative sizes they abses won't make much of a difference. Sure. r~