From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6995 invoked by alias); 17 Mar 2007 18:03:58 -0000 Received: (qmail 6940 invoked by alias); 17 Mar 2007 18:03:47 -0000 Date: Sat, 17 Mar 2007 18:03:00 -0000 Message-ID: <20070317180347.6939.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug tree-optimization/31169] Bootstrap comparison error at revision 122821 In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "dave at hiauly1 dot hia dot nrc dot ca" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-03/txt/msg01682.txt.bz2 ------- Comment #22 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-17 18:03 ------- Subject: Re: Bootstrap comparison error at revision 122821 > I'll recheck with the third hunk. j_5: [0, 12048173] EQUIVALENCES: { } (0 elements) There isn't any difference in the code generated with and without the third hunk. Also, stage1 through stage3 with hunk generate the same code at -O2. As far as I can tell, the code is correct in all cases. > > If the count is actually zero, we can end up doing x << 0 (a left shift of > > zero). Does hppa handle this correctly? Does it, for > The hardware doesn't support a left shift of zero, so at the moment > the expanders and patterns require that the shift length be greater > than zero. Sorry, the above statement is wrong. What the hardware doesn't support is zero length deposits. Deposit instructions are used for shifts. In the case of an ashift with a CONST_INT shift amount x, the deposit length is 32 - (INTVAL (x) & 31). So, the deposit length is [1, 32]. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31169