From patchwork Tue Jul 31 11:51:21 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Alan Modra X-Patchwork-Id: 174254 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 35A262C0092 for ; Tue, 31 Jul 2012 21:51:48 +1000 (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=1344340309; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Date:From:To:Cc:Subject:Message-ID: Mail-Followup-To:References:MIME-Version:Content-Type: Content-Disposition:In-Reply-To:User-Agent:Mailing-List: Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:Sender:Delivered-To; bh=yQjWUt+Z1nQMBUbkgUIWIWUWwwo=; b=jjkcGsHOtsKCrXnE+KXcOFx+EH5CAVpQvMm0nNv5YvVk7TJ2IswIfcG7hqT16d tq/9qOli1FaxZLYPyy8l2nvvw8YxSXEQty5/UvPKXBO7HWlX0DMoDbEX6iB/nI2g CullU5YkG6o8JgMZ/980Nge8Wd9mGTh7bkCoG7v194TDk= 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:Received:Date:From:To:Cc:Subject:Message-ID:Mail-Followup-To:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:User-Agent:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=iFd22okzuHbjK4q+OMmLBEkK8e7mLuZgLbR2CI0MkiUPTLXWTzGzQyWwEdfQ1a u7Q3ok8zlyrP1CmkT/ddigXVmCfFMIpzSSkVJvEIw+vipymjvyk7CYR9cgee/pRP Pw77At1tZ69bv2GUIU1QqxG0cftgXAewDNncFh+vAI8D8=; Received: (qmail 16885 invoked by alias); 31 Jul 2012 11:51:44 -0000 Received: (qmail 16875 invoked by uid 22791); 31 Jul 2012 11:51:42 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-gh0-f175.google.com (HELO mail-gh0-f175.google.com) (209.85.160.175) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Jul 2012 11:51:29 +0000 Received: by ghbz2 with SMTP id z2so5925355ghb.20 for ; Tue, 31 Jul 2012 04:51:28 -0700 (PDT) Received: by 10.66.75.162 with SMTP id d2mr31710874paw.59.1343735488354; Tue, 31 Jul 2012 04:51:28 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id rs4sm158703pbc.0.2012.07.31.04.51.25 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 Jul 2012 04:51:27 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 8ADF3EA30AD; Tue, 31 Jul 2012 21:21:21 +0930 (CST) Date: Tue, 31 Jul 2012 21:21:21 +0930 From: Alan Modra To: David Edelsohn , Pat Haugen Cc: gcc-patches@gcc.gnu.org Subject: [RS6000] Fix PR54131, ICE building 416.gamess Message-ID: <20120731115121.GS3182@bubble.grove.modra.org> Mail-Followup-To: David Edelsohn , Pat Haugen , gcc-patches@gcc.gnu.org References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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 cures the 'Y' constraint of being overly restrictive with lo_sum offsets. I've added a comment that explains why it is wrong to limit the range of lo_sum offsets. Bootstrapped and regressiotn tested powerpc-linux. OK to apply? PR target/54131 * config/rs6000/rs6000.c (mem_operand_gpr): Don't limit range of lo_sum offsets. Comment. Assert mode at least word size rather than bypassing powerpc64 word offset check. Index: gcc/config/rs6000/rs6000.c =================================================================== --- gcc/config/rs6000/rs6000.c (revision 189996) +++ gcc/config/rs6000/rs6000.c (working copy) @@ -5008,24 +5008,38 @@ Offsetting a lo_sum should not be allowed, except where we know by alignment that a 32k boundary is not crossed, but see the ??? - comment in rs6000_legitimize_reload_address. */ + comment in rs6000_legitimize_reload_address. Note that by + "offsetting" here we mean a further offset to access parts of the + MEM. It's fine to have a lo_sum where the inner address is offset + from a sym, since the same sym+offset will appear in the high part + of the address calculation. */ bool mem_operand_gpr (rtx op, enum machine_mode mode) { unsigned HOST_WIDE_INT offset; int extra; + rtx addr = XEXP (op, 0); - op = address_offset (XEXP (op, 0)); + op = address_offset (addr); if (op == NULL_RTX) return true; offset = INTVAL (op); + if (TARGET_POWERPC64 && (offset & 3) != 0) + return false; + + if (GET_CODE (addr) == LO_SUM) + /* We know by alignment that ABI_AIX medium/large model toc refs + will not cross a 32k boundary, since all entries in the + constant pool are naturally aligned and we check alignment for + other medium model toc-relative addresses. For ABI_V4 and + ABI_DARWIN lo_sum addresses, we just check that 64-bit + offsets are 4-byte aligned. */ + return true; + extra = GET_MODE_SIZE (mode) - UNITS_PER_WORD; - if (extra < 0) - extra = 0; - else if (TARGET_POWERPC64 && (offset & 3) != 0) - return false; + gcc_assert (extra >= 0); return offset + 0x8000 < 0x10000u - extra; }