From patchwork Tue Nov 20 17:29:52 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 200489 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 23F252C0089 for ; Wed, 21 Nov 2012 04:30:23 +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=1354037424; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:From:To:Mail-Followup-To:Cc:Subject:References:Date: In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type: Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:Sender:Delivered-To; bh=jaRF2L5bD0ffLUjm/GsC dheKjOI=; b=iZ0xdgzwOCTlhaFmzdF+QkY+0sAQ9QjC4rgYbh/tN80ZoEl8tBXn kiCajVd2HTZbZyaKuEuC/b3yiWUkv39medMhzCVJzNkV/bAm1W0qh3I4guhLLnuN fTFbG0Qbs+d+RIHZ7JNo/eYMVH+y395cJTXxN3vWkNhamK7822RrxIM= 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:From:To:Mail-Followup-To:Cc:Subject:References:Date:In-Reply-To:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=K0Mfz2KLMB6wd+J9x5pqqx8ZowUOXJMoyMF9QYXqfhdBOHsttFDXGAp2Ph7aRl 0BJlm03jrLAI707tNfbBL6RMAX/zngLYKOUpmjGqAX7DTiXSmxxFjM4yYB+Cx5/r wnfJNoitiDRFqc2HnQrS1v7NZxuVQZrkcMdz3xvn0hgoc=; Received: (qmail 14055 invoked by alias); 20 Nov 2012 17:30:07 -0000 Received: (qmail 14030 invoked by uid 22791); 20 Nov 2012 17:30:05 -0000 X-SWARE-Spam-Status: No, hits=-3.8 required=5.0 tests=AWL, BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, KHOP_RCVD_TRUST, NML_ADSP_CUSTOM_MED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-bk0-f47.google.com (HELO mail-bk0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Nov 2012 17:29:57 +0000 Received: by mail-bk0-f47.google.com with SMTP id j4so1112610bkw.20 for ; Tue, 20 Nov 2012 09:29:56 -0800 (PST) Received: by 10.204.129.214 with SMTP id p22mr6363928bks.47.1353432595943; Tue, 20 Nov 2012 09:29:55 -0800 (PST) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com (gbibp9ph1--blueice1n1.emea.ibm.com. [195.212.29.67]) by mx.google.com with ESMTPS id i20sm3455708bkw.5.2012.11.20.09.29.53 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Nov 2012 09:29:54 -0800 (PST) From: Richard Sandiford To: Richard Henderson Mail-Followup-To: Richard Henderson , GCC Patches , rdsandiford@googlemail.com Cc: GCC Patches Subject: Re: [PATCH, RFC] PR 55403 + 55391 References: <50ABB04E.5070705@redhat.com> <87txskusct.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <50ABB997.3070400@redhat.com> Date: Tue, 20 Nov 2012 17:29:52 +0000 In-Reply-To: <50ABB997.3070400@redhat.com> (Richard Henderson's message of "Tue, 20 Nov 2012 09:10:47 -0800") Message-ID: <87pq38uqr3.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 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 Richard Henderson writes: > On 11/20/2012 08:55 AM, Richard Sandiford wrote: >> but what kind of bitfield memory were we trying to >> create in the ICE case? The idea was that "adjust_object" is only ever >> true for bitfield adjustments. We should then either be using an >> integer or field mode whose size is picked up by: >> >> if (defattrs->size_known_p) >> size = defattrs->size; >> >> or a BLKmode whose value is passed in via adjust_bitfield_address_size. >> It sounds like I missed a case where the latter was needed. > > A TFmode field of an unaligned TCmode original. We do wind up with > a BLKmode extraction, without the _size passed in. Gah. How about this patch, currently bootstrapping on x86_64-linux-gnu as a sanity check? The last instance seems glaringly obvious in hindsight :-( Richard gcc/ * expmed.c (store_bit_field_1): Use adjust_bitfield_address_size rather than adjust_bitfield_address to change the mode of a reference. (extract_bit_field_1): Likewise. Index: gcc/expmed.c =================================================================== --- gcc/expmed.c 2012-11-20 09:55:26.000000000 +0000 +++ gcc/expmed.c 2012-11-20 17:24:09.722871322 +0000 @@ -645,7 +645,7 @@ store_bit_field_1 (rtx str_rtx, unsigned if (imode != GET_MODE (op0)) { if (MEM_P (op0)) - op0 = adjust_bitfield_address (op0, imode, 0); + op0 = adjust_bitfield_address_size (op0, imode, 0, MEM_SIZE (op0)); else { gcc_assert (imode != BLKmode); @@ -1380,7 +1380,7 @@ extract_bit_field_1 (rtx str_rtx, unsign if (imode != GET_MODE (op0)) { if (MEM_P (op0)) - op0 = adjust_bitfield_address (op0, imode, 0); + op0 = adjust_bitfield_address_size (op0, imode, 0, MEM_SIZE (op0)); else if (imode != BLKmode) { op0 = gen_lowpart (imode, op0); @@ -1403,10 +1403,10 @@ extract_bit_field_1 (rtx str_rtx, unsign } else { - rtx mem = assign_stack_temp (GET_MODE (op0), - GET_MODE_SIZE (GET_MODE (op0))); + HOST_WIDE_INT size = GET_MODE_SIZE (GET_MODE (op0)); + rtx mem = assign_stack_temp (GET_MODE (op0), size); emit_move_insn (mem, op0); - op0 = adjust_bitfield_address (mem, BLKmode, 0); + op0 = adjust_bitfield_address_size (mem, BLKmode, 0, size); } } }