From patchwork Tue Oct 17 00:39:52 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 153833 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2908:b0:403:3b70:6f57 with SMTP id ib8csp3815206vqb; Mon, 16 Oct 2023 17:40:31 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGJCvemCHaK7P/u+NzCuT/OXpYf9x5kN2UfdV5fAjNqh0N+csVCTlecFKdookVu8vg+Rvsq X-Received: by 2002:ae9:f204:0:b0:76f:f0b:a1b8 with SMTP id m4-20020ae9f204000000b0076f0f0ba1b8mr705840qkg.25.1697503231339; Mon, 16 Oct 2023 17:40:31 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1697503231; cv=pass; d=google.com; s=arc-20160816; b=I3XOibCTdy6QLRw2fiXo3JWYOw6WxQUiUta8bsk+1cuLKZr7WeePRCzgzlpYvFEsJn +i9VldwaKyrF3Sppqg9cyZdpaxRxAXHnHa8a/os3eZWyzDLAz75yPwx8/GkYefRdwDkS LrIB9XP1WeZC81Sb1wjTAv3HqrrDoEH2z+7fwIr0uQ8InLm9QzKvOlCpi6kH8dhiNvqb 3hPqDq8hAqoi6mrEyiuzQ9sptEwmNLIsITkSfe+blwO3ERxfBBMwUAcqI2JsOkNcZig1 KUI2ktFtjLqeuyJOnLEpDB7xUe0azW4Xf0KngzucVxRjyYAsu20owdB4oCwnlboQd7B9 MFbA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=errors-to:list-subscribe:list-help:list-post:list-archive :list-unsubscribe:list-id:precedence:content-disposition:user-agent :in-reply-to:mime-version:references:message-id:subject:cc:to:from :date:dkim-signature:arc-filter:dmarc-filter:delivered-to; bh=vDGUw03YeC/uKwWRt4yyB3dXxKZHYej050DPxs/cuV8=; fh=rsfJLMIL/7j+58qzkgIXBlfQSah3iXypQc76SN5PqTs=; b=Psp6htY5wT5wvO2W9Q+rxp96V5UoWmi+kQ6NIWY4sFyJrh2iNKnsyulMiGufKq7zGj +CubKOSpK/Aw6rQlBgS6Owk79+D9Qw0fdY8ylNWenLyILV1SgdKuvm5k3isA5cWH4aRl 0vufjeryDWAcsKUwqihrGoyTjLasYxJCHN9Wc0lnwiZb9KOODc14T2gQZKkNxBe1JYO6 o6nyLYl1ufVXpRacUgexLMn5k6lVIhLjDWuPAxwQenjwoe+INfDmvRKgbHBf133vx+tr OWxIkd8FgTfHvST4IjmtRouE3vhVLHI7PqxolOrV5wszI9OEYCHaiKbQxF8GC38MFflk tV2Q== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SMVt2F9L; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id c6-20020a05620a0ce600b00774351019f7si308514qkj.411.2023.10.16.17.40.31 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 17:40:31 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=SMVt2F9L; arc=pass (i=1); spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D2311385703D for ; Tue, 17 Oct 2023 00:40:27 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 08F813858D37 for ; Tue, 17 Oct 2023 00:39:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 08F813858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 08F813858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697503200; cv=none; b=eN6lIDemnsfOoO4eMxlJ4YZ2dKBUpXqA5OkzuMQJQg93fl4TWQAYPjgHdZRmrQvR+KrES5rqU3mBQMGY3hltprmXKAl/lqJliYi7qtyD1xdJ5fgf22Sgt9Qt1InZcKk0H50FDug6sD/bF/5FwbtQ+vfH0T+Of95gIzmnAfcof2s= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1697503200; c=relaxed/simple; bh=s3OV25yXWe2dzkCMpxShyS71aa0OAPoIPH8hoNCItKk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=xO0l5mYPdqnqtIfMBvT7wf7DkqDIsl3d8tFS9JUaB08HgWLSlAwQiCzJ0crUA7ipeZt0fTL0ZbKCEOrV0p3h2BLZlusk2onWljOnlCrC2QnF2llwprZMGdsGPjjkk5y3jVvnGfltCmquOqBU56wIVcAkCjrVWmW4llkUcdCwq2o= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1697503197; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=vDGUw03YeC/uKwWRt4yyB3dXxKZHYej050DPxs/cuV8=; b=SMVt2F9LtC/bWP103/7mjzK7xm5WGd6Rvws0peWbZUto0OyINxZ8wSxsjdi8eTvSkdQjha /8XjYcd62p2JbJkt3YZncrKBAV2THB8BJXqSyVRobn4SCns3d9nlSYc+V2XvvCbhbhsG4L dfW0uxHgzMFBO+JlXSV0rm17YhCmWNY= Received: from mail-vs1-f71.google.com (mail-vs1-f71.google.com [209.85.217.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-187-hYQIfrAwNIWChwsvod31TQ-1; Mon, 16 Oct 2023 20:39:56 -0400 X-MC-Unique: hYQIfrAwNIWChwsvod31TQ-1 Received: by mail-vs1-f71.google.com with SMTP id ada2fe7eead31-457bc611991so1721746137.0 for ; Mon, 16 Oct 2023 17:39:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697503195; x=1698107995; h=user-agent:in-reply-to:content-disposition:mime-version:references :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=vDGUw03YeC/uKwWRt4yyB3dXxKZHYej050DPxs/cuV8=; b=KZxUD2TodE1LPrr7qEA6UdgddEApfYVf2KaJTfZMvqZfEoER0R+wkp7ylPNxcKc6+D 4qFQomf5aM2Cnfu/recQU1GC1Th8pUFKtBxHAzGnK8GBx6uDH0UO5ELjmj6qHf3/uVOI Dutswn9emdpvKw27A3xWjp1Lkm3yTWmJyfqMPGWHXQyi6v8wnMk2Q5NlZq6hoQyA/Wbl iBc7FRyJ2PB7NUJCbKKXVCMqyG26NiHThzrBW72MBSu57Ef20GQXgNM0c/nwPIWuQ0In H2VGulEN5fgPDf52ofD0ndo2dWgOSziCKDkMabeggTXBMMLq05Vffj8w/fQo9yworOic wusw== X-Gm-Message-State: AOJu0YwQZl0zobGZrUrvktvOF8cgzHxZfcFqiDWsZdQdHUppTUte5HnF wRgQt7zW7Qe/BpieCyHcx4C3voRtCWCAbBAkLlvzA9Kqe66+bAoOrqmbNYliibm8ZIwxyB884TZ 1bVsZZdg9jv0hrkaytVMPszWfGw== X-Received: by 2002:a67:c113:0:b0:457:c49c:bc63 with SMTP id d19-20020a67c113000000b00457c49cbc63mr1067014vsj.6.1697503195303; Mon, 16 Oct 2023 17:39:55 -0700 (PDT) X-Received: by 2002:a67:c113:0:b0:457:c49c:bc63 with SMTP id d19-20020a67c113000000b00457c49cbc63mr1067004vsj.6.1697503194854; Mon, 16 Oct 2023 17:39:54 -0700 (PDT) Received: from redhat.com (2603-7000-9500-34a5-0000-0000-0000-1db4.res6.spectrum.com. [2603:7000:9500:34a5::1db4]) by smtp.gmail.com with ESMTPSA id mi6-20020a056214558600b0065d105f6931sm126504qvb.59.2023.10.16.17.39.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Oct 2023 17:39:54 -0700 (PDT) Date: Mon, 16 Oct 2023 20:39:52 -0400 From: Marek Polacek To: Jason Merrill Cc: GCC Patches Subject: [PATCH v3] c++: Fix compile-time-hog in cp_fold_immediate_r [PR111660] Message-ID: References: <20231012210426.755503-1-polacek@redhat.com> <58e6893f-178e-4732-9c96-b52c38ad37c5@redhat.com> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/2.2.9 (2022-11-12) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, RCVD_IN_SORBS_WEB, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1779585207875623275 X-GMAIL-MSGID: 1779961148406557546 On Sat, Oct 14, 2023 at 01:13:22AM -0400, Jason Merrill wrote: > On 10/13/23 14:53, Marek Polacek wrote: > > On Thu, Oct 12, 2023 at 09:41:43PM -0400, Jason Merrill wrote: > > > On 10/12/23 17:04, Marek Polacek wrote: > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > > > > > -- >8 -- > > > > My recent patch introducing cp_fold_immediate_r caused exponential > > > > compile time with nested COND_EXPRs. The problem is that the COND_EXPR > > > > case recursively walks the arms of a COND_EXPR, but after processing > > > > both arms it doesn't end the walk; it proceeds to walk the > > > > sub-expressions of the outermost COND_EXPR, triggering again walking > > > > the arms of the nested COND_EXPR, and so on. This patch brings the > > > > compile time down to about 0m0.033s. > > > > > > > > I've added some debug prints to make sure that the rest of cp_fold_r > > > > is still performed as before. > > > > > > > > PR c++/111660 > > > > > > > > gcc/cp/ChangeLog: > > > > > > > > * cp-gimplify.cc (cp_fold_immediate_r) : Return > > > > integer_zero_node instead of break;. > > > > (cp_fold_immediate): Return true if cp_fold_immediate_r returned > > > > error_mark_node. > > > > > > > > gcc/testsuite/ChangeLog: > > > > > > > > * g++.dg/cpp0x/hog1.C: New test. > > > > --- > > > > gcc/cp/cp-gimplify.cc | 9 ++-- > > > > gcc/testsuite/g++.dg/cpp0x/hog1.C | 77 +++++++++++++++++++++++++++++++ > > > > 2 files changed, 82 insertions(+), 4 deletions(-) > > > > create mode 100644 gcc/testsuite/g++.dg/cpp0x/hog1.C > > > > > > > > diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc > > > > index bdf6e5f98ff..ca622ca169a 100644 > > > > --- a/gcc/cp/cp-gimplify.cc > > > > +++ b/gcc/cp/cp-gimplify.cc > > > > @@ -1063,16 +1063,16 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) > > > > break; > > > > if (TREE_OPERAND (stmt, 1) > > > > && cp_walk_tree (&TREE_OPERAND (stmt, 1), cp_fold_immediate_r, data, > > > > - nullptr)) > > > > + nullptr) == error_mark_node) > > > > return error_mark_node; > > > > if (TREE_OPERAND (stmt, 2) > > > > && cp_walk_tree (&TREE_OPERAND (stmt, 2), cp_fold_immediate_r, data, > > > > - nullptr)) > > > > + nullptr) == error_mark_node) > > > > return error_mark_node; > > > > /* We're done here. Don't clear *walk_subtrees here though: we're called > > > > from cp_fold_r and we must let it recurse on the expression with > > > > cp_fold. */ > > > > - break; > > > > + return integer_zero_node; > > > > > > I'm concerned this will end up missing something like > > > > > > 1 ? 1 : ((1 ? 1 : 1), immediate()) > > > > > > as the integer_zero_node from the inner ?: will prevent walk_tree from > > > looking any farther. > > > > You are right. The line above works as expected, but > > > > 1 ? 1 : ((1 ? 1 : id (42)), id (i)); > > > > shows the problem (when the expression isn't used as an initializer). > > > > > Maybe we want to handle COND_EXPR in cp_fold_r instead of here? > > > > I hope this version is better. > > > > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? > > > > -- >8 -- > > My recent patch introducing cp_fold_immediate_r caused exponential > > compile time with nested COND_EXPRs. The problem is that the COND_EXPR > > case recursively walks the arms of a COND_EXPR, but after processing > > both arms it doesn't end the walk; it proceeds to walk the > > sub-expressions of the outermost COND_EXPR, triggering again walking > > the arms of the nested COND_EXPR, and so on. This patch brings the > > compile time down to about 0m0.033s. > > Is this number still accurate for this version? It is. I ran time(1) a few more times and the results were 0m0.033s - 0m0.035s. That said, ... > This change seems algorithmically better than the current code, but still > problematic: if we have nested COND_EXPR A/B/C/D/E, it looks like we will > end up cp_fold_immediate_r walking the arms of E five times, once for each > COND_EXPR. ...this is accurate. I should have addressed the redundant folding in v2 even though the compilation is pretty much immediate. > What I was thinking by handling COND_EXPR in cp_fold_r was to cp_fold_r walk > its subtrees (or cp_fold_immediate_r if it's clear from op0 that the branch > isn't taken) so we can clear *walk_subtrees and we don't fold_imm walk a > node more than once. I agree I should do better here. How's this, then? I've added debug_generic_expr to cp_fold_immediate_r to see if it gets the same expr multiple times and it doesn't seem to. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? -- >8 -- My recent patch introducing cp_fold_immediate_r caused exponential compile time with nested COND_EXPRs. The problem is that the COND_EXPR case recursively walks the arms of a COND_EXPR, but after processing both arms it doesn't end the walk; it proceeds to walk the sub-expressions of the outermost COND_EXPR, triggering again walking the arms of the nested COND_EXPR, and so on. This patch brings the compile time down to about 0m0.030s. The ff_fold_immediate flag is unused after this patch but since I'm using it in the P2564 patch, I'm not removing it now. Maybe at_eof can be used instead and then we can remove ff_fold_immediate. PR c++/111660 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_fold_immediate_r) : Don't handle it here. (cp_fold_r): Handle COND_EXPR here. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/hog1.C: New test. * g++.dg/cpp2a/consteval36.C: New test. --- gcc/cp/cp-gimplify.cc | 52 +++++++++------- gcc/testsuite/g++.dg/cpp0x/hog1.C | 77 ++++++++++++++++++++++++ gcc/testsuite/g++.dg/cpp2a/consteval36.C | 22 +++++++ 3 files changed, 128 insertions(+), 23 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/hog1.C create mode 100644 gcc/testsuite/g++.dg/cpp2a/consteval36.C base-commit: 328745607c5d403a1c7b6bc2ecaa1574ee42122f diff --git a/gcc/cp/cp-gimplify.cc b/gcc/cp/cp-gimplify.cc index bdf6e5f98ff..a282c3930a3 100644 --- a/gcc/cp/cp-gimplify.cc +++ b/gcc/cp/cp-gimplify.cc @@ -1052,27 +1052,6 @@ cp_fold_immediate_r (tree *stmt_p, int *walk_subtrees, void *data_) switch (TREE_CODE (stmt)) { - /* Unfortunately we must handle code like - false ? bar () : 42 - where we have to check bar too. The cp_fold call in cp_fold_r could - fold the ?: into a constant before we see it here. */ - case COND_EXPR: - /* If we are called from cp_fold_immediate, we don't need to worry about - cp_fold folding away the COND_EXPR. */ - if (data->flags & ff_fold_immediate) - break; - if (TREE_OPERAND (stmt, 1) - && cp_walk_tree (&TREE_OPERAND (stmt, 1), cp_fold_immediate_r, data, - nullptr)) - return error_mark_node; - if (TREE_OPERAND (stmt, 2) - && cp_walk_tree (&TREE_OPERAND (stmt, 2), cp_fold_immediate_r, data, - nullptr)) - return error_mark_node; - /* We're done here. Don't clear *walk_subtrees here though: we're called - from cp_fold_r and we must let it recurse on the expression with - cp_fold. */ - break; case PTRMEM_CST: if (TREE_CODE (PTRMEM_CST_MEMBER (stmt)) == FUNCTION_DECL && DECL_IMMEDIATE_FUNCTION_P (PTRMEM_CST_MEMBER (stmt))) @@ -1162,8 +1141,35 @@ cp_fold_r (tree *stmt_p, int *walk_subtrees, void *data_) tree stmt = *stmt_p; enum tree_code code = TREE_CODE (stmt); - if (cxx_dialect > cxx17) - cp_fold_immediate_r (stmt_p, walk_subtrees, data); + if (cxx_dialect >= cxx20) + { + /* Unfortunately we must handle code like + false ? bar () : 42 + where we have to check bar too. The cp_fold call below could + fold the ?: into a constant before we've checked it. */ + if (code == COND_EXPR) + { + auto then_fn = cp_fold_r, else_fn = cp_fold_r; + /* See if we can figure out if either of the branches is dead. If it + is, we don't need to do everything that cp_fold_r does. */ + tree cond = maybe_constant_value (TREE_OPERAND (stmt, 0)); + if (integer_zerop (cond)) + then_fn = cp_fold_immediate_r; + else if (TREE_CODE (cond) == INTEGER_CST) + else_fn = cp_fold_immediate_r; + + cp_walk_tree (&TREE_OPERAND (stmt, 0), cp_fold_r, data, nullptr); + if (TREE_OPERAND (stmt, 1)) + cp_walk_tree (&TREE_OPERAND (stmt, 1), then_fn, data, + nullptr); + if (TREE_OPERAND (stmt, 2)) + cp_walk_tree (&TREE_OPERAND (stmt, 2), else_fn, data, + nullptr); + *walk_subtrees = 0; + /* Don't return yet, still need the cp_fold below. */ + } + cp_fold_immediate_r (stmt_p, walk_subtrees, data); + } *stmt_p = stmt = cp_fold (*stmt_p, data->flags); diff --git a/gcc/testsuite/g++.dg/cpp0x/hog1.C b/gcc/testsuite/g++.dg/cpp0x/hog1.C new file mode 100644 index 00000000000..105a2e912c4 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/hog1.C @@ -0,0 +1,77 @@ +// PR c++/111660 +// { dg-do compile { target c++11 } } + +enum Value { + LPAREN, + RPAREN, + LBRACE, + RBRACE, + LBRACK, + RBRACK, + CONDITIONAL, + COLON, + SEMICOLON, + COMMA, + PERIOD, + BIT_OR, + BIT_AND, + BIT_XOR, + BIT_NOT, + NOT, + LT, + GT, + MOD, + ASSIGN, + ADD, + SUB, + MUL, + DIV, + PRIVATE_NAME, + STRING, + TEMPLATE_SPAN, + IDENTIFIER, + WHITESPACE, + ILLEGAL, +}; + +constexpr Value GetOneCharToken(char c) { + return + c == '(' ? LPAREN : + c == ')' ? RPAREN : + c == '{' ? LBRACE : + c == '}' ? RBRACE : + c == '[' ? LBRACK : + c == ']' ? RBRACK : + c == '?' ? CONDITIONAL : + c == ':' ? COLON : + c == ';' ? SEMICOLON : + c == ',' ? COMMA : + c == '.' ? PERIOD : + c == '|' ? BIT_OR : + c == '&' ? BIT_AND : + c == '^' ? BIT_XOR : + c == '~' ? BIT_NOT : + c == '!' ? NOT : + c == '<' ? LT : + c == '>' ? GT : + c == '%' ? MOD : + c == '=' ? ASSIGN : + c == '+' ? ADD : + c == '-' ? SUB : + c == '*' ? MUL : + c == '/' ? DIV : + c == '#' ? PRIVATE_NAME : + c == '"' ? STRING : + c == '\'' ? STRING : + c == '`' ? TEMPLATE_SPAN : + c == '\\' ? IDENTIFIER : + c == ' ' ? WHITESPACE : + c == '\t' ? WHITESPACE : + c == '\v' ? WHITESPACE : + c == '\f' ? WHITESPACE : + c == '\r' ? WHITESPACE : + c == '\n' ? WHITESPACE : + ILLEGAL; +} + +int main() {} diff --git a/gcc/testsuite/g++.dg/cpp2a/consteval36.C b/gcc/testsuite/g++.dg/cpp2a/consteval36.C new file mode 100644 index 00000000000..9c470e4b7d7 --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp2a/consteval36.C @@ -0,0 +1,22 @@ +// PR c++/111660 +// { dg-do compile { target c++20 } } + +consteval int id (int i) { return i; } + +void +g (int i) +{ + 1 ? 1 : ((1 ? 1 : 1), id (i)); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? 1 : 1), id (i), 1); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((i ? 1 : 1), id (i), 1); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? i : 1), id (i), 1); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? 1 : i), id (i), 1); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((i ? -i : i), id (i), 1); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? 1 : id (i)), id (42), 1); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? 1 : id (42)), id (i)); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? 1 : id (42)), id (i), 1); // { dg-error "'i' is not a constant expression" } + id (i) ? 1 : ((1 ? 1 : 1), id (i)); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((1 ? 1 : id (i)), id (i)); // { dg-error "'i' is not a constant expression" } + 1 ? id (i) : ((1 ? 1 : id (i)), id (i)); // { dg-error "'i' is not a constant expression" } + 1 ? 1 : ((id (i) ? 1 : 1), id (i)); // { dg-error "'i' is not a constant expression" } +}