From patchwork Wed Nov 4 11:57:45 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Mike Stump X-Patchwork-Id: 539812 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]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id CE8E31402D7 for ; Wed, 4 Nov 2015 22:58:48 +1100 (AEDT) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=LDcP7dRj; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= default; b=Q2J7OWSgFVHWJ/qM6JDprV3yuaikkznFGzEuYjvZM/kz2AxPXyQ9L qoivNMJLfoaHz4HS/4fq7tq4Q6SqqkNuFT9taMy5GowDqKB8kyAcruFqE54CXK6Y +1BuPZ5A3JUep3tMPpQAMIvZltqxAm4BxGuR8Iz3ld40CxJXKr2+f0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=default; bh=JyqBAxDcmXFbT8R4PznmDDPGW08=; b=LDcP7dRjJk44d32i2p7btcyc0n7o KdvzcaZG0BAsRvwCHqjmhBxm+RXU/CnB85D6yBrdA7pJYGdh5rGzgP3LpS78AuOY JolBjMGq0bvLe+zLGSRRvMt5jXDA2ooRDLHvxkgTaHarndmyYktsewozHBBtgBGL TDxFuib3E0Wtvys= Received: (qmail 79444 invoked by alias); 4 Nov 2015 11:58:40 -0000 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 Received: (qmail 79431 invoked by uid 89); 4 Nov 2015 11:58:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=BAYES_00, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_PASS, T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: resqmta-po-04v.sys.comcast.net Received: from resqmta-po-04v.sys.comcast.net (HELO resqmta-po-04v.sys.comcast.net) (96.114.154.163) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 04 Nov 2015 11:58:38 +0000 Received: from resomta-po-17v.sys.comcast.net ([96.114.154.241]) by resqmta-po-04v.sys.comcast.net with comcast id dPyc1r0045Clt1L01Pyc3V; Wed, 04 Nov 2015 11:58:36 +0000 Received: from [IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d] ([IPv6:2001:558:6045:a4:40c6:7199:cd03:b02d]) by resomta-po-17v.sys.comcast.net with comcast id dPya1r00D2ztT3H01PybHy; Wed, 04 Nov 2015 11:58:36 +0000 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [ping] Fix PR debug/66728 From: Mike Stump In-Reply-To: Date: Wed, 4 Nov 2015 03:57:45 -0800 Cc: Richard Sandiford , Bernd Schmidt , Ulrich Weigand , GCC Patches Message-Id: <7ADD4B03-BF3E-48BA-8028-AC5EB50E773C@comcast.net> References: <20151028115839.1E7C85C3D@oc7340732750.ibm.com> <87ziz3ta4t.fsf@e105548-lin.cambridge.arm.com> <5630D8AE.1090608@redhat.com> <87h9l4v2pi.fsf@e105548-lin.cambridge.arm.com> <87611kuzz4.fsf@e105548-lin.cambridge.arm.com> <871tc8unnx.fsf@e105548-lin.cambridge.arm.com> <87wptztqpx.fsf@e105548-lin.cambridge.arm.com> <29C8CB44-A0EC-4A9A-A4D3-3ABB6D66DA5B@comcast.net> To: Richard Biener X-IsSubscribed: yes On Nov 4, 2015, at 1:43 AM, Richard Biener wrote: > I think you should limit the effect of this patch to the dwarf2out use > as the above doesn't make sense to me. Since dwarf is so special, and since other clients already do something sort of like this anyway, it isn’t unreasonable to make the client be responsible for picking a sensible mode, and asserting if they fail to. This also transfers the cost of the special case code out to the one client that needs it, and avoids that cost for all the other clients. The new patch is below for your consideration. Ok? > Ideally we'd have an assert that you don't create a rtx_mode_t with > VOIDmode or BLKmode. Added. > Handling the CONST_WIDE_INT in dwarf2out.c the same as we did before > (with CONST_DOUBLE) > looks sensible as far of fixing a regression (I assume the diff to the > dwarf results in essentially the > same DWARF as what was present before wide-int). Yes, the dwarf is the same. Index: dwarf2out.c =================================================================== --- dwarf2out.c (revision 229720) +++ dwarf2out.c (working copy) @@ -15593,8 +15593,15 @@ return true; case CONST_WIDE_INT: - add_AT_wide (die, DW_AT_const_value, - std::make_pair (rtl, GET_MODE (rtl))); + { + machine_mode mode = GET_MODE (rtl); + if (mode == VOIDmode) + mode = mode_for_size (CONST_WIDE_INT_NUNITS (rtl) + * HOST_BITS_PER_WIDE_INT, + MODE_INT, 0); + add_AT_wide (die, DW_AT_const_value, + std::make_pair (rtl, mode)); + } return true; case CONST_DOUBLE: Index: rtl.h =================================================================== --- rtl.h (revision 229720) +++ rtl.h (working copy) @@ -2086,6 +2086,7 @@ inline unsigned int wi::int_traits ::get_precision (const rtx_mode_t &x) { + gcc_assert (x.second != BLKmode && x.second != VOIDmode); return GET_MODE_PRECISION (x.second); }