From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32496 invoked by alias); 17 Oct 2009 14:42:11 -0000 Received: (qmail 32486 invoked by uid 22791); 17 Oct 2009 14:42:10 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from eastrmmtao107.cox.net (HELO eastrmmtao107.cox.net) (68.230.240.59) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Oct 2009 14:42:06 +0000 Received: from eastrmimpo01.cox.net ([68.1.16.119]) by eastrmmtao107.cox.net (InterMail vM.8.00.01.00 201-2244-105-20090324) with ESMTP id <20091017144202.LOGM19505.eastrmmtao107.cox.net@eastrmimpo01.cox.net> for ; Sat, 17 Oct 2009 10:42:02 -0400 Received: from [192.168.1.118] ([24.254.236.21]) by eastrmimpo01.cox.net with bizsmtp id tqi21c0030UP1Qg02qi24k; Sat, 17 Oct 2009 10:42:02 -0400 X-VR-Score: -100.00 X-Authority-Analysis: v=1.0 c=1 a=kviXuzpPAAAA:8 a=85qMpHC9fXBB9ut01KQA:9 a=jeudW5p3FLmjNmpXAYAA:7 a=1-JZOy73XFEvSKr-dbkEihPYzz4A:4 a=4vB-4DCPJfMA:10 X-CM-Score: 0.00 Message-ID: <4AD9D7D8.5020201@cox.net> Date: Sat, 17 Oct 2009 16:18:00 -0000 From: Andrew Hutchinson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: GCC Development Subject: Re: Bug in binop rotate ? References: <4AD9CAE6.8070404@cox.net> <84fc9c000910170714u31f922bgb6f197348d089465@mail.gmail.com> In-Reply-To: <84fc9c000910170714u31f922bgb6f197348d089465@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-10/txt/msg00381.txt.bz2 Thanks for your review. I have submitted bug report. Richard Guenther wrote: > On Sat, Oct 17, 2009 at 3:47 PM, Andrew Hutchinson > wrote: > >> I have been adding rotate capability to AVR port and have come across what I >> think is bug in >> optabs.c: expand_binop() >> >> This occurs during a rotate expansion. For example >> >> target = op0 rotated by op1 >> >> In the particular situation (code extract below) it tries a reverse rotate >> of (bits - op1). Where this expression is expanded as a simple integer, >> a negation or subtraction depending on type of op1 and target. >> >> The expansion of the subtraction is using the mode of the target - I believe >> it should be using the mode of op1. >> The mode of the rotation amount need not be the same as the target. >> >> target:DI = Op0:DI rotate op1:HI >> >> In my testcase it is not and I get asserts latter in simplfy_rtx. >> >> The negation mode looks equally wrong. >> >> Am I mistaken? >> > > I think you are correct. > > Richard. > > >> /* If we were trying to rotate, and that didn't work, try rotating >> the other direction before falling back to shifts and bitwise-or. */ >> if (((binoptab == rotl_optab >> && optab_handler (rotr_optab, mode)->insn_code != CODE_FOR_nothing) >> || (binoptab == rotr_optab >> && optab_handler (rotl_optab, mode)->insn_code != CODE_FOR_nothing)) >> && mclass == MODE_INT) >> { >> optab otheroptab = (binoptab == rotl_optab ? rotr_optab : rotl_optab); >> rtx newop1; >> unsigned int bits = GET_MODE_BITSIZE (mode); >> >> if (CONST_INT_P (op1)) >> newop1 = GEN_INT (bits - INTVAL (op1)); >> else if (targetm.shift_truncation_mask (mode) == bits - 1) >> newop1 = negate_rtx (mode, op1); >> else >> newop1 = expand_binop (mode, sub_optab, >> GEN_INT (bits), op1, >> NULL_RTX, unsignedp, OPTAB_DIRECT); >> >> > >