From patchwork Tue Nov 20 16:31:10 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Henderson X-Patchwork-Id: 200394 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 4601B2C031D for ; Wed, 21 Nov 2012 03:31:43 +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=1354033904; h=Comment: DomainKey-Signature: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=1xIUQnf zsYi76l9FskXnYHGUwWI=; b=g+DlfVTYcTBoWpwMYF3GCrNX9Vf9ttbOX2GpfHQ o8BQJOc1u6Qd34ds/Rccay2gEsjxdHLXbPMSMTxU5JW0fYN+54CWCuQsjs7VB9kg saXbOFDF41RPJEmMEBYn+0sfmxanVWmRkewDCEYJ86U/F3jDpii82he6To2Qyh5g vdzY= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=FeZyjzjR7QcJXAZmR7ngUnFSD2krwXmx6SeBwGWyg+OuB10xn0QZIxAkDdONuS sDlSncbytRPNbJkVz0iMdTVadoBYOwQhZfgZxL6RFIGJO1dnBXUyj4B0WO/y4R8G i1DwDqlVNMqEldUfgluGqWZSUNww1WmcTeAsZQ4Zw+Q9U=; Received: (qmail 3337 invoked by alias); 20 Nov 2012 16:31:23 -0000 Received: (qmail 3244 invoked by uid 22791); 20 Nov 2012 16:31:20 -0000 X-SWARE-Spam-Status: No, hits=-5.7 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, RP_MATCHES_RCVD, SPF_HELO_PASS, SUBJ_ALL_CAPS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Nov 2012 16:31:12 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qAKGVBj8026857 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Nov 2012 11:31:11 -0500 Received: from anchor.twiddle.home (vpn-230-194.phx2.redhat.com [10.3.230.194]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qAKGVAUK019807; Tue, 20 Nov 2012 11:31:11 -0500 Message-ID: <50ABB04E.5070705@redhat.com> Date: Tue, 20 Nov 2012 08:31:10 -0800 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Richard Sandiford , GCC Patches Subject: [PATCH, RFC] PR 55403 + 55391 X-IsSubscribed: yes 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 This assert looks to me like a "can this ever happen" sort of check. It quite apparently can. Although I'm a bit curious about the reasons we got to this point in the 55403 instance (unaligned TCmode memory, extracting a TFmode value), it's clear that one could intentionally write such a thing, rather than have it happen by accident, and that it should work. The following fills in what appears to be a blank. I assume this is the sort of thing you'd have intended? I'm just doing another round of testing now... r~ * emit-rtl.c (adjust_address_1): Handle adjust_object for size_known_p instead of asserting it isn't set. diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c index 27464da..dd3339c 100644 --- a/gcc/emit-rtl.c +++ b/gcc/emit-rtl.c @@ -2177,7 +2177,11 @@ adjust_address_1 (rtx memref, enum machine_mode mode, HOST_WIDE_INT offset, } else if (attrs.size_known_p) { - gcc_assert (!adjust_object); + if (adjust_object) + { + attrs.expr = NULL_TREE; + attrs.alias = 0; + } attrs.size -= offset; /* ??? The store_by_pieces machinery generates negative sizes, so don't assert for that here. */