From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13379 invoked by alias); 16 Sep 2008 21:40:08 -0000 Received: (qmail 13371 invoked by uid 22791); 16 Sep 2008 21:40:07 -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; Tue, 16 Sep 2008 21:39:32 +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 m8GLZUfA030242; Tue, 16 Sep 2008 17:35:30 -0400 Received: from hs20-bc2-1.build.redhat.com (hs20-bc2-1.build.redhat.com [10.10.28.34]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m8GLZTCb030873; Tue, 16 Sep 2008 17:35:29 -0400 Received: from hs20-bc2-1.build.redhat.com (localhost.localdomain [127.0.0.1]) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1) with ESMTP id m8GLZTr2004011; Tue, 16 Sep 2008 17:35:29 -0400 Received: (from jakub@localhost) by hs20-bc2-1.build.redhat.com (8.13.1/8.13.1/Submit) id m8GLZT0w004007; Tue, 16 Sep 2008 17:35:29 -0400 Date: Tue, 16 Sep 2008 21:55:00 -0000 From: Jakub Jelinek To: Peter Bergner Cc: sje@cup.hp.com, 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 Message-ID: <20080916213528.GM20215@hs20-bc2-1.build.redhat.com> Reply-To: Jakub Jelinek References: <200809161651.m8GGpEM19079@lucas.cup.hp.com> <1221589231.6367.14.camel@sjoa> <1221590867.17787.18.camel@hpsje.cup.hp.com> <1221591757.6367.20.camel@sjoa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1221591757.6367.20.camel@sjoa> User-Agent: Mutt/1.4.1i 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-09/txt/msg01166.txt.bz2 On Tue, Sep 16, 2008 at 02:02:37PM -0500, Peter Bergner wrote: > On Tue, 2008-09-16 at 11:47 -0700, Steve Ellcey wrote: > > On Tue, 2008-09-16 at 13:20 -0500, Peter Bergner wrote: > > I guess I am not sure why setting REG_POINTER on a hard register is bad. > > I looked at PR 36533 but it did not enlighten me. > > Jakub, what was the exact problem having the REG_POINTER attribute set on > a hard register cause on x86 again? The problem is that unlike pseudo registers, a hard register can contain different kinds of variables over the lifetime of a function. So, it can be a pointer for part of a function and non-pointer for another part of the function. Or it can contain two different pointers with different alignments, yet REGNO_POINTER_ALIGN is a shared value for particular REGNO inside of the whole function. Jakub