From patchwork Wed Jan 18 11:48:45 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Aurelien Buhrig X-Patchwork-Id: 136604 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 1D185B6EF1 for ; Wed, 18 Jan 2012 22:48:06 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1327492087; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=hoPzajA OksiouypLSWItI6gmzl8=; b=HyEpJ0vVqcc6F4RL0q1vtwm9TUiPcfrAVx0DjTS bDKN2Z3bFYEcfwM+fP6FM5zpDK3dCOW9Gu1HJokH9ksHqDKpS++CcbMswtaFQLjZ 3gDaY/+3XZ2nbXp7Ze70y3VSZkPjDSL+VaCyjlr7ZFeJqCCgwPc641JlO0ZroPU1 h3JA= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=gJSfXT963UqvjDfl50EfX0Ll9y56KYrfLve9cEoqHb6KivOI2idMq/P+uY6hsF LUUpmu9+iShZTgmds2bhsYLQUW26bbcZa5X7vaRAKEaEPatI2jipaa/XMKLBfPuu q0wCWS2geiLkvVPlL7SMB2ZEFzYUoWl5z60pbi/mtrMzs=; Received: (qmail 17431 invoked by alias); 18 Jan 2012 11:48:02 -0000 Received: (qmail 17372 invoked by uid 22791); 18 Jan 2012 11:48:01 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-lpp01m010-f47.google.com (HELO mail-lpp01m010-f47.google.com) (209.85.215.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Jan 2012 11:47:49 +0000 Received: by lami14 with SMTP id i14so2945287lam.20 for ; Wed, 18 Jan 2012 03:47:47 -0800 (PST) Received: by 10.112.103.131 with SMTP id fw3mr5051081lbb.78.1326887267518; Wed, 18 Jan 2012 03:47:47 -0800 (PST) Received: from [10.15.38.183] (LCaen-156-54-3-113.w80-11.abo.wanadoo.fr. [80.11.66.113]) by mx.google.com with ESMTPS id jn4sm18065602lab.16.2012.01.18.03.47.45 (version=SSLv3 cipher=OTHER); Wed, 18 Jan 2012 03:47:46 -0800 (PST) Message-ID: <4F16B19D.5050806@gmail.com> Date: Wed, 18 Jan 2012 12:48:45 +0100 From: Aurelien Buhrig User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: gcc-patches@gcc.gnu.org Subject: Bug store_bit_field_1 + patch Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Hi, I've found a bug in store_bit_field_1 for BIG_ENDIAN targets whose words are HI. The testcase is execute.exp=bitfld-3.c for my target (which is not public). It occurs on 4.6.1 release, but seem to be present in trunk (looking at the code, not executed). The problem occurs when value is a REG and bitsize > BITS_PER_WORD. This is because wordnum, which is used to get the subword of value, is incorrectly computed, in BIG_ENDIAN, wrt the number of words needed by bitsize instead of the number of words needed by the integer mode of the field, which is the mode used to compute subwords. For instance, for a 40bit field to be set by a DI reg (with HI words), the offset of the LSWord of the DI reg should be 3, not 2 as currently computed. The following patch seems to solve the issue. Tested on the C testsuite without any regression (for my target only). Hope it helps, Aurélien --- expmed.c.orig 2012-01-18 11:48:21.000000000 +0100 +++ expmed.c 2012-01-18 11:49:19.000000000 +0100 @@ -589,7 +589,10 @@ { /* If I is 0, use the low-order word in both field and target; if I is 1, use the next to lowest word; and so on. */ - unsigned int wordnum = (backwards ? nwords - i - 1 : i); + unsigned int wordnum = (backwards + ? GET_MODE_SIZE(fieldmode)/UNITS_PER_WORD + - i - 1 + : i); unsigned int bit_offset = (backwards ? MAX ((int) bitsize - ((int) i + 1) * BITS_PER_WORD,