From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26390 invoked by alias); 21 Dec 2018 02:49:45 -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 26378 invoked by uid 89); 21 Dec 2018 02:49:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=cp_fold, Hmm, Sometimes, cp_fold_rvalue X-HELO: mail-qk1-f195.google.com Received: from mail-qk1-f195.google.com (HELO mail-qk1-f195.google.com) (209.85.222.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 21 Dec 2018 02:49:43 +0000 Received: by mail-qk1-f195.google.com with SMTP id q70so2284983qkh.6 for ; Thu, 20 Dec 2018 18:49:43 -0800 (PST) Return-Path: Received: from [192.168.1.149] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id k6sm7948598qkk.60.2018.12.20.18.49.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Dec 2018 18:49:40 -0800 (PST) Subject: Re: [C++ PATCH] Fix __builtin_{is_constant_evaluated,constant_p} handling in static_assert (PR c++/86524, PR c++/88446) To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20181212223037.GL12380@tucnak> <310c40c2-ee1c-8a96-0e09-098ffbb1dba1@redhat.com> <20181220210812.GQ23305@tucnak> <20181220214035.GR23305@tucnak> <20181220222719.GS23305@tucnak> From: Jason Merrill Message-ID: <4abcfe78-7e84-5188-6616-ddba47d9a5bd@redhat.com> Date: Fri, 21 Dec 2018 02:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <20181220222719.GS23305@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-12/txt/msg01526.txt.bz2 On 12/20/18 5:27 PM, Jakub Jelinek wrote: > 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? Ah, no, good point. > 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? I think that would be better, yes. Jason