From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27089 invoked by alias); 6 Nov 2008 21:38:41 -0000 Received: (qmail 27057 invoked by uid 22791); 6 Nov 2008 21:38:40 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 06 Nov 2008 21:38:04 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id mA6LXxOJ026594; Thu, 6 Nov 2008 16:33:59 -0500 Received: from omfg.slc.redhat.com (vpn-13-102.rdu.redhat.com [10.11.13.102]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id mA6LXuDl029118; Thu, 6 Nov 2008 16:33:56 -0500 Message-ID: <4913621E.90508@redhat.com> Date: Thu, 06 Nov 2008 22:05:00 -0000 From: Jeff Law User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: David Edelsohn CC: luisgpm@linux.vnet.ibm.com, Andrew Pinski , sje@cup.hp.com, Richard Henderson , Peter Bergner , gcc-patches@gcc.gnu.org, paolo.carlini@oracle.com Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX References: <303e1d290811061151l43701067pcfb7725fdc73f31c@mail.gmail.com> In-Reply-To: <303e1d290811061151l43701067pcfb7725fdc73f31c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; 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: 2008-11/txt/msg00256.txt.bz2 David Edelsohn wrote: > Jeff, > > The RTL is a pair of (high (symbol_ref)) and (lo_sum (reg) (symbol_ref)). > Presumably at the point in question we're looking at the lo_sum insn, right? > alias.c:find_base_value() has a special case for lo_sum: > > case LO_SUM: > /* The standard form is (lo_sum reg sym) so look only at the > second operand. */ > return find_base_value (XEXP (src, 1)); > > However, find_base_term() throws lo_sum in with PLUS and MINUS, > which prefers the REG. find_base_term() appears to expect that the > symbol_ref from the HIGH will be recorded with the REG and picked > up by the LO_SUM from that source. > > find_base_term() either could check for non-zero base before returning > in the lo_sum/plus/minus case statement or could handle lo_sum > explicitly, like find_base_value(). > I think my suggestion will accomplish the same thing -- and it makes logical sense too -- if we can't determine something from the pointer reg, then we look at other info, such as the symbol_ref within a lo_sum. Jeff