From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29607 invoked by alias); 16 Sep 2008 19:03:50 -0000 Received: (qmail 29597 invoked by uid 22791); 16 Sep 2008 19:03:49 -0000 X-Spam-Check-By: sourceware.org Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.150) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 16 Sep 2008 19:02:56 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id m8GIt8US028743 for ; Tue, 16 Sep 2008 14:55:08 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id m8GJ2hGw055272 for ; Tue, 16 Sep 2008 13:02:43 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m8H12dca026675 for ; Tue, 16 Sep 2008 19:02:42 -0600 Received: from [9.10.86.196] (sjoa.rchland.ibm.com [9.10.86.196]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m8H12bM3026603; Tue, 16 Sep 2008 19:02:37 -0600 Subject: Re: Patch to fix gcc.c-torture/compile/20010102-1.c on IA64 HP-UX From: Peter Bergner To: sje@cup.hp.com Cc: gcc-patches@gcc.gnu.org, paolo.carlini@oracle.com, Jakub Jelinek In-Reply-To: <1221590867.17787.18.camel@hpsje.cup.hp.com> References: <200809161651.m8GGpEM19079@lucas.cup.hp.com> <1221589231.6367.14.camel@sjoa> <1221590867.17787.18.camel@hpsje.cup.hp.com> Content-Type: text/plain Date: Tue, 16 Sep 2008 19:40:00 -0000 Message-Id: <1221591757.6367.20.camel@sjoa> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 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-09/txt/msg01153.txt.bz2 On Tue, 2008-09-16 at 11:47 -0700, Steve Ellcey wrote: > On Tue, 2008-09-16 at 13:20 -0500, Peter Bergner wrote: > > > Would it make more sense to call gen_reg_rtx_and_attrs() and > > set_reg_attrs_from_value() to get/set the REG_ATTRS and REG_POINTER > > fields? There was also a bug (PR36533), where we shouldn't set the > > REG_POINTER attribute for hard registers. I'm not sure if that's > > possible here, but it doesn't seem to be checked. Using > > set_reg_attrs_from_value() would protect us from that. > > > > Peter > > I think I need to have REG_POINTER set on hard registers. The failure I > was getting is: > > (insn:TI 1149 1480 1148 45 (set (reg:DI 2 r2 [699]) > (unspec:DI [ > (plus:SI (reg:SI 3 r3 [orig:697 .object_base ] > [697]) > (reg/v:SI 15 r15 [orig:627 i.69 ] [627])) > ] 24)) -1 (nil)) > 20010102-1.c:101: internal compiler error: in get_attr_first_insn, at > config/ia64/itanium2.md:1838 > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > > The problem is that neither r3 or r15 are marked as pointers and so I > don't match my addp4 instruction template. Does the REG_POINTER > attribute have to be true or false for the entire life of the hard > register? It seems obvious that as different values are put into a hard > register, sometimes it will have a pointer and sometimes it will not. Correct, the REG_POINTER attribute is true/false for the entire use of the hard register, even though it can contain many unrelated values and that was the basic problem. > 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? Peter