From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24010 invoked by alias); 24 Jan 2004 01:36:01 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 23955 invoked by alias); 24 Jan 2004 01:36:00 -0000 Date: Sat, 24 Jan 2004 01:36:00 -0000 Message-ID: <20040124013600.23954.qmail@sources.redhat.com> From: "zack at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040117230657.13722.schwab@suse.de> References: <20040117230657.13722.schwab@suse.de> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/13722] [3.4/3.5 regression] [ia64] ICE in push_secondary_reload X-Bugzilla-Reason: CC X-SW-Source: 2004-01/txt/msg03041.txt.bz2 List-Id: ------- Additional Comments From zack at codesourcery dot com 2004-01-24 01:35 ------- Subject: Re: PR 13722 candidate fix Jim Wilson writes: > On Fri, 2004-01-23 at 00:47, Zack Weinberg wrote: >> Re-revised patch. > > On the REG/SUBREG issue, I was looking at your latest patch. In the > full context of the previous patch, I see you already handle most of > these issues by having a default switch case that aborts. Yes. I think there are good /a priori/ reasons to assume that we won't ever get SUBREGs here, so I think this is adequate. (A SUBREG in the operand itself could only be paradoxical, and shouldn't survive this far; a SUBREG in the MEM expression would either be paradoxical, and again shouldn't have survived this far, or would take it out of Pmode and therefore indicate a bug elsewhere.) > The only real issue I see here is in the POST_MODIFY code where you > have > + if (GET_CODE (XEXP (offset, 1)) == REG) > ... > + else if (INTVAL (XEXP (offset, 1)) < -256 + 8) > which assumes without checking that the offset is a CONST_INT if it > isn't a REG. I put in an abort to see if this ever happens, but I doubt > that it does. The theory here was that INTVAL would trigger an RTL checking abort if offset wasn't a CONST_INT, so there was no need for an explicit check. I now remember that RTL checking isn't on by default, so an explicit check would probably be wise. > I see you have another modified patch. I can try this when my current > build finishes. I would appreciate that. zw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13722