From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1206 invoked by alias); 28 Feb 2012 00:38:36 -0000 Received: (qmail 1198 invoked by uid 22791); 28 Feb 2012 00:38:36 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 28 Feb 2012 00:38:23 +0000 From: "kkojima at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/52394] SH Target: SH2A defunct bitops Date: Tue, 28 Feb 2012 00:49:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: kkojima at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-02/txt/msg02637.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52394 --- Comment #1 from Kazumoto Kojima 2012-02-28 00:37:56 UTC --- I guess that now these tests require -fno-strict-volatile-bitfields, though it isn't enough to avoid failures. It looks that something wrong happens in expmed.c:{store, extract}_bit_field_1 and they decide to use slow fallback {store, extract}_fixed_bit_field instead of generating insv/extv. Here is suspicious part of {store, extract}_bit_field_1: /* Now convert from counting within UNIT to counting in EXT_MODE. */ if (BYTES_BIG_ENDIAN && !MEM_P (xop0)) xbitpos += GET_MODE_BITSIZE (ext_mode) - unit; unit = GET_MODE_BITSIZE (ext_mode); /* If BITS_BIG_ENDIAN is zero on a BYTES_BIG_ENDIAN machine, we count "backwards" from the size of the unit we are extracting from. Otherwise, we count bits from the most significant on a BYTES/BITS_BIG_ENDIAN machine. */ if (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN) xbitpos = unit - bitsize - xbitpos; In the problematic cases, xop0 is a QImode memory and ext_mode is SImode. The initial value of unit is 8. When starting xbitops is 3 and bitsize is 1 for example, these lines set xbitspos to 28! There is no insv/extv which inserts/extracts such bit position for QImode memory and maybe_expand_insn for CODE_FOR_{insv, extv} fails. Perhaps, these parts should be something like /* We have been counting XBITPOS within UNIT. Count instead within the size of the register. */ if (BYTES_BIG_ENDIAN && !MEM_P (xop0)) xbitpos += GET_MODE_BITSIZE (op_mode) - unit; /* If BITS_BIG_ENDIAN is zero on a BYTES_BIG_ENDIAN machine, we count "backwards" from the size of the unit we are inserting into. Otherwise, we count bits from the most significant on a BYTES/BITS_BIG_ENDIAN machine. */ if (BITS_BIG_ENDIAN != BYTES_BIG_ENDIAN) { if (!MEM_P (xop0)) xbitpos = GET_MODE_BITSIZE (op_mode) - bitsize - xbitpos; else xbitpos = unit - bitsize - xbitpos; } unit = GET_MODE_BITSIZE (op_mode); though I don't understand these routines well.