From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85855 invoked by alias); 20 Dec 2018 22:27:27 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 85838 invoked by uid 89); 20 Dec 2018 22:27:27 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=Hmm, Sometimes X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 20 Dec 2018 22:27:25 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1304573 for ; Thu, 20 Dec 2018 22:27:24 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-117-214.ams2.redhat.com [10.36.117.214]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 9BE265DF29; Thu, 20 Dec 2018 22:27:23 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id wBKMRLqj028878; Thu, 20 Dec 2018 23:27:21 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id wBKMRKOE028877; Thu, 20 Dec 2018 23:27:20 +0100 Date: Thu, 20 Dec 2018 22:41:00 -0000 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446) Message-ID: <20181220222719.GS23305@tucnak> Reply-To: Jakub Jelinek References: <20181212223037.GL12380@tucnak> <310c40c2-ee1c-8a96-0e09-098ffbb1dba1@redhat.com> <20181220210812.GQ23305@tucnak> <20181220214035.GR23305@tucnak> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01513.txt.bz2 On Thu, Dec 20, 2018 at 04:47:29PM -0500, Jason Merrill wrote: > > So are you ok with what is in the patch below, i.e. > > { > > bool non_cst_p = false, ovf_p = false; > > tree a = cxx_eval_constant_expression (&new_ctx, args[i], false, > > &non_cst_p, &ovf_p); > > if ((!non_cst_p && !ovf_p) || !ctx->manifestly_const_eval) > > args[i] = a; > > } > > , or perhaps without the || !ctx->manifestly_const_eval? > > I don't see how that makes a difference from what was there before; if the > argument to cxx_eval_constant_expression is non-constant, it returns the > argument unchanged. If that is guaranteed, then it is ok to keep it as is I guess. Will change it then. > > So, if the > > argument is a constant expression, fold to that, if it is not, just do > > cp_fully_fold on it if it is __builtin_constant_p, otherwise nothing? > > Hmm, cp_fully_fold probably also needs to add a manifestly_const_eval > parameter to pass along to maybe_constant_value. But if we need cp_fully_fold, doesn't that mean that the earlier cxx_eval_constant_expression failed and thus the argument is not a constant expression? Should __builtin_is_constant_evaluated () evaluate to true even if the argument is not a constant expression? Say if there is int v; constexpr int foo (void) { return __builtin_constant_p (v * (__builtin_is_constant_evaluated () ? 1 : 0)); } Because v is not a constant expression, v * (__builtin_is_constant_evaluated () ? 1 : 0) shouldn't be either. cp_fully_fold does: /* FIXME cp_fold ought to be a superset of maybe_constant_value so we don't have to call both. */ if (cxx_dialect >= cxx11) { x = maybe_constant_value (x); /* Sometimes we are given a CONSTRUCTOR but the call above wraps it into a TARGET_EXPR; undo that here. */ if (TREE_CODE (x) == TARGET_EXPR) x = TARGET_EXPR_INITIAL (x); else if (TREE_CODE (x) == VIEW_CONVERT_EXPR && TREE_CODE (TREE_OPERAND (x, 0)) == CONSTRUCTOR && TREE_TYPE (TREE_OPERAND (x, 0)) == TREE_TYPE (x)) x = TREE_OPERAND (x, 0); } return cp_fold_rvalue (x); Is there a reason to call that maybe_constant_value at all when we've called cxx_eval_constant_expression first? Wouldn't cp_fold_rvalue (or c_fully_fold with false as last argument) be sufficient there? Jakub