From patchwork Tue Aug 26 16:01:46 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 383167 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 7258C140078 for ; Wed, 27 Aug 2014 02:02:05 +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 :message-id:date:from:mime-version:to:cc:subject:content-type; q=dns; s=default; b=IiYVVoYSjNJSAiOtzC1/dlLxQp4CGepCi/jYSiL1MsA dLVt2nvGBYq1pYq99d0DVjgK8hThzGOrMcjLzMpRu0VL28kfikMmMrxTyki922LK dPgIDpA1IA2o3fue/3D2gISFBHCUuZGezQ225EPAbUDGqugBEeo+OiGZDqGrJfys = 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 :message-id:date:from:mime-version:to:cc:subject:content-type; s=default; bh=OiPP/T+wWSzBzj8eot99/Bx0D3M=; b=KHl/uI8OmFLc8k3BE rQYdH1sG7bHKFnOaH6KX3i4D7piojWIhSy62CFE64d9vVpL7ODXsfA70IS4yTKWg HTQ2CfaFsogjrQ4Oe3Mjo4rHhK25lnWk7Z9WXxiAvMr5aUcRLeHBS/kp/ya9l2uK fPYVSpjGexuWLh7lk1Ta/I/ZKw= Received: (qmail 31079 invoked by alias); 26 Aug 2014 16:01:59 -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 31064 invoked by uid 89); 26 Aug 2014 16:01:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_PASS autolearn=ham version=3.3.2 X-HELO: userp1040.oracle.com Received: from userp1040.oracle.com (HELO userp1040.oracle.com) (156.151.31.81) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Tue, 26 Aug 2014 16:01:55 +0000 Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s7QG1qlg018771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 26 Aug 2014 16:01:53 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s7QG1pYb017301 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Aug 2014 16:01:52 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userz7022.oracle.com (8.14.5+Sun/8.14.4) with ESMTP id s7QG1ohp012201; Tue, 26 Aug 2014 16:01:50 GMT Received: from [192.168.1.4] (/79.33.191.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 26 Aug 2014 09:01:49 -0700 Message-ID: <53FCAF6A.5060507@oracle.com> Date: Tue, 26 Aug 2014 18:01:46 +0200 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "gcc-patches@gcc.gnu.org" CC: Jason Merrill Subject: [C++ RFH/Patch] PR 52892 (and others) X-IsSubscribed: yes Hi, it would be nice to make progress on some constexpr issues, thus I started looking more closely into c++/52892, which comes with a compact testcase and a useful comparison with a snippet for which we already do the right thing (thanks to Daniel). Thus: constexpr bool is_negative(int x) { return x < 0; } constexpr bool check(int x, bool (*p)(int)) { return p(x); } static_assert(check(-2, is_negative), "Error"); vs constexpr bool is_negative(int x) { return x < 0; } typedef bool (*Function)(int); constexpr bool check(int x, Function p) { return p(x); } static_assert(check(-2, is_negative), "Error"); the difference, for the latter and for more complex cases, is that adjust_temp_type calls cp_fold_convert which ends up returning a NOP_EXPR (eg, build in fold_convert_loc). This NOP_EXPR eventually appears as return value of the cxx_eval_constant_expression at the beginning of cxx_eval_call_expression. Of course, there are many different ways in which such NOP_EXPR can be returned and, well, if only we could look through it, we would find an ADDR_EXPR and all such cases (eg, in c++/52282 too) would be easily handled by the rest of cxx_eval_call_expression. Today I wondered: at least when we are *sure* that we are handling a function pointer, would it be correct to actually use STRIP_NOPS on what cxx_eval_constant_expression returns?!? The attached passes testing anyway... Thanks, Paolo Carlini Index: semantics.c =================================================================== --- semantics.c (revision 214492) +++ semantics.c (working copy) @@ -8389,8 +8389,12 @@ cxx_eval_call_expression (const constexpr_call *ol if (TREE_CODE (fun) != FUNCTION_DECL) { /* Might be a constexpr function pointer. */ + bool is_fptr = TYPE_PTRFN_P (TREE_TYPE (fun)); fun = cxx_eval_constant_expression (old_call, fun, allow_non_constant, - /*addr*/false, non_constant_p, overflow_p); + /*addr*/false, non_constant_p, + overflow_p); + if (is_fptr) + STRIP_NOPS (fun); if (TREE_CODE (fun) == ADDR_EXPR) fun = TREE_OPERAND (fun, 0); }