From patchwork Thu Mar 24 13:49:10 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Brown X-Patchwork-Id: 88199 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 71223B6F90 for ; Fri, 25 Mar 2011 00:49:26 +1100 (EST) Received: (qmail 15010 invoked by alias); 24 Mar 2011 13:49:23 -0000 Received: (qmail 14995 invoked by uid 22791); 24 Mar 2011 13:49:21 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL, BAYES_00, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 24 Mar 2011 13:49:17 +0000 Received: (qmail 8655 invoked from network); 24 Mar 2011 13:49:15 -0000 Received: from unknown (HELO rex.config) (julian@127.0.0.2) by mail.codesourcery.com with ESMTPA; 24 Mar 2011 13:49:15 -0000 Date: Thu, 24 Mar 2011 13:49:10 +0000 From: Julian Brown To: Richard Sandiford Cc: Chung-Lin Tang , gcc-patches Subject: Re: [patch] Fix PR48183, NEON ICE in emit-rtl.c:immed_double_const() under -g Message-ID: <20110324134910.19d9c755@rex.config> In-Reply-To: References: <4D85DEA1.6070606@codesourcery.com> Mime-Version: 1.0 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 On Thu, 24 Mar 2011 10:57:06 +0000 Richard Sandiford wrote: > Chung-Lin Tang writes: > > PR48183 is a case where ARM NEON instrinsics, under -O -g, produce > > debug insns that tries to expand OImode (32-byte integer) zero > > constants, much too large to represent as two HOST_WIDE_INTs; as > > the internals manual indicates, such large constants are not > > supported in general, and ICEs on the GET_MODE_BITSIZE(mode) == > > 2*HOST_BITS_PER_WIDE_INT assertion. > > > > This patch allows the cases where the large integer constant is > > still representable using a single CONST_INT, such as zero(0). > > Bootstrapped and tested on i686 and x86_64, cross-tested on ARM, > > all without regressions. Okay for trunk? > > > > Thanks, > > Chung-Lin > > > > 2011-03-20 Chung-Lin Tang > > > > * emit-rtl.c (immed_double_const): Allow wider than > > 2*HOST_BITS_PER_WIDE_INT mode constants when they are > > representable as a single const_int RTX. > > I realise this might be seen as a good expedient fix, but it makes > me a bit uneasy. Not a very constructive rationale, sorry. FWIW I also had a "fix" for this issue, which is equivalent to Chung-Lin's patch apart from only allowing constant-zero (attached). That's not really a vote from me for this approach, but maybe limiting the extent to which we pretend to support wide-integer constants like this is sensible, if we do go that way. Julian --- gcc/expr.c (revision 314639) +++ gcc/expr.c (working copy) @@ -8458,6 +8458,18 @@ expand_expr_real_1 (tree exp, rtx target return decl_rtl; case INTEGER_CST: + if (GET_MODE_BITSIZE (mode) > 2 * HOST_BITS_PER_WIDE_INT) + { + /* FIXME: We can't generally represent wide integer constants, + but GCC sometimes tries to initialise wide integer values (such + as used by the ARM NEON support) with zero. Handle that as a + special case here. */ + if (initializer_zerop (exp)) + return CONST0_RTX (mode); + + gcc_unreachable (); + } + temp = immed_double_const (TREE_INT_CST_LOW (exp), TREE_INT_CST_HIGH (exp), mode);