From patchwork Mon May 19 10:03:22 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 350201 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 90D82140076 for ; Mon, 19 May 2014 20:03:37 +1000 (EST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; q=dns; s=default; b=ehw8sPKZ/T2kWDn0 1xzV8ZDqQoUkloZTJowb0QbzkGlNaTNRGEubO5TGnHLu31W4VicoPCXh0wrazco/ T+85Fh7lV/sXRsX/84C9eXIQVD7F2SHw4Z0x0qaIaozZzraoZOV8zNXXvzXcULtn 3tOSbDEJnLtZtlL2ccbGNatdHtk= 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:from :to:cc:subject:references:date:in-reply-to:message-id :mime-version:content-type; s=default; bh=JPL710FEY/09ugXS+5xtBe fQ2Jw=; b=sLbYMDteEXTtZSaQl0hriuPl6zirlDPQbtC5Cc9jdeFhKT8X9mC2Cm GZEXcdDV5Go0DkHRgn8ljDfW0IGPhUAlblNmEI+qwgYIZKfvUJ1LkZLpaqCsmEAv DKKw4ypRdkOS6bafjekGHNGVC+2Jgm2GmKP5nes22BSVxYUU9KGBQ= Received: (qmail 28116 invoked by alias); 19 May 2014 10:03:29 -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 28103 invoked by uid 89); 19 May 2014 10:03:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f45.google.com Received: from mail-wg0-f45.google.com (HELO mail-wg0-f45.google.com) (74.125.82.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 19 May 2014 10:03:27 +0000 Received: by mail-wg0-f45.google.com with SMTP id m15so7493771wgh.4 for ; Mon, 19 May 2014 03:03:24 -0700 (PDT) X-Received: by 10.180.103.5 with SMTP id fs5mr11844171wib.33.1400493804104; Mon, 19 May 2014 03:03:24 -0700 (PDT) Received: from sandifor-thinkpad.stglab.manchester.uk.ibm.com ([2.26.169.52]) by mx.google.com with ESMTPSA id dn4sm14197686wib.18.2014.05.19.03.03.23 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 May 2014 03:03:23 -0700 (PDT) From: Richard Sandiford To: Richard Biener Mail-Followup-To: Richard Biener , GCC Patches , rdsandiford@googlemail.com Cc: GCC Patches Subject: Re: Replace C/C++ void_zero_node with a VOID_CST tree code References: <87mwegzuqz.fsf@talisman.default> <87ppjaglt5.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> Date: Mon, 19 May 2014 11:03:22 +0100 In-Reply-To: (Richard Biener's message of "Mon, 19 May 2014 11:42:24 +0200") Message-ID: <87lhtygk5x.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Richard Biener writes: > On Mon, May 19, 2014 at 11:27 AM, Richard Sandiford > wrote: >> Richard Biener writes: >>> On Sat, May 17, 2014 at 10:15 AM, Richard Sandiford >>> wrote: >>>> The main thing keeping zero-precision wide-ints alive was void_zero_node, >>>> a tree used in the C and C++ frontends that has type VOID_TYPE but code >>>> INTEGER_CST. >>>> >>>> Richard B. asked me to replace the INTEGER_CST with a new constant type, >>>> here called VOID_CST. Most of it is straight-forward. The one perhaps >>>> controversial bit is that C++ uses void_(zero_)node to represent dummy >>>> objects when e.g. taking the address of a member function without an >>>> associated object. IIUC the node used in this situation needs to be >>>> distinct from anything that could occur in user code and therefore couldn't >>>> be a simple null pointer. >>>> >>>> This reaches the gimplifier in cases like >>>> g++.old-deja/g++.brendan/operators4.C. I chose to handle it in the >>>> gimplifier, since void_zero_node was previously handled there too, >>>> although perhaps by accident. If you object strongly to this then >>>> I'll need pretty detailed instructions about what to do instead, >>>> i.e. exactly which parts of the C++ front end need to be changed >>>> in order for dummy objects never to escape. >>> >>> I suppose it reaches the gimplifier because it's not handled in >>> fold-const.c:fold_convert_loc while the INTEGER_CST void_zero_node >>> was (through fold_convert_const). >> >> But like I said, void_zero_node reached the gimplifier too. Try adding: >> >> gcc_assert (TREE_TYPE (TREE_OPERAND (*expr_p, 0)) != void_type_node >> || TREE_CODE (TREE_OPERAND (*expr_p, 0)) != INTEGER_CST); >> >> to gimplify_conversion and running g++.old-deja/g++.brendan/operators4.C >> to see what I mean. >> >>> That said, only handling (T)void_cst in gimplification looks like >>> a hack. If necessary we'd want to treat it as construct-T-with-zero-value >>> consistently. >> >> OK, so just remove the gcc_checking_assert? > > Which one? The one I'd added to the gimplifier: > I'd add VOID_CST handling to fold_convert_const. But like you say, if that was enough, void_zero_node would never have reached the gimplifier, whereas as above it does. I tried adding: gcc_assert (TREE_CODE (arg1) != VOID_CST); to fold_convert_const and it doesn't trigger for operators4.C. It also doesn't trigger for g++-mike/p10769b.C, which was the other main motivating case. Thanks, Richard Index: gcc/gimplify.c =================================================================== --- gcc/gimplify.c 2014-05-15 13:49:24.483656013 +0100 +++ gcc/gimplify.c 2014-05-16 17:55:17.087700837 +0100 @@ -1681,7 +1681,15 @@ gimplify_conversion (tree *expr_p) /* Then strip away all but the outermost conversion. */ STRIP_SIGN_NOPS (TREE_OPERAND (*expr_p, 0)); - /* And remove the outermost conversion if it's useless. */ + /* Support C++-style dummy objects, in which void_zero is + cast to a pointer type. We treat these as null pointers. */ + if (TREE_OPERAND (*expr_p, 0) == void_node) + { + gcc_checking_assert (POINTER_TYPE_P (TREE_TYPE (*expr_p))); + *expr_p = build_int_cst (TREE_TYPE (*expr_p), 0); + } + + /* Remove the outermost conversion if it's useless. */ if (tree_ssa_useless_type_conversion (*expr_p)) *expr_p = TREE_OPERAND (*expr_p, 0);