public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "junk at sigpwr dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/104507] [10/11 Regression] internal compiler error: unexpected expression ‘(int)(__ret)’ of kind cast_expr Date: Sun, 13 Feb 2022 08:47:11 +0000 [thread overview] Message-ID: <bug-104507-4-nFjgWhTF5l@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-104507-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104507 --- Comment #2 from Daniel Nelson <junk at sigpwr dot com> --- Had a few moments to do some testing/bisecting, and found the commit that fixed this in mainline. commit 9927ecbb42d5be48fa933adc26f8601fab5007ca Author: Patrick Palka <ppalka@redhat.com> Date: Thu Oct 28 10:05:14 2021 -0400 c++: quadratic constexpr behavior for left-assoc logical exprs [PR102780] In the testcase below the two left fold expressions each expand into a constant logical expression with 1024 terms, for which potential_const_expr takes more than a minute to return true. This happens because p_c_e_1 performs trial evaluation of the first operand of a &&/|| in order to determine whether to consider the potentiality of the second operand. And because the expanded expression is left-associated, this trial evaluation causes p_c_e_1 to be quadratic in the number of terms of the expression. This patch fixes this quadratic behavior by making p_c_e_1 preemptively compute potentiality of the second operand of a &&/||, and perform trial evaluation of the first operand only if the second operand isn't potentially constant. We must be careful to avoid emitting bogus diagnostics during the preemptive computation; to that end, we perform this shortcut only when tf_error is cleared, and when tf_error is set we now first check potentiality of the whole expression quietly and replay the check noisily for diagnostics. Apart from fixing the quadraticness for left-associated logical exprs, this change also reduces compile time for the libstdc++ testcase 20_util/variant/87619.cc by about 15% even though our <variant> uses right folds instead of left folds. Likewise for the testcase in the PR, for which compile time is reduced by 30%. The reason for these speedups is that p_c_e_1 no longer performs expensive trial evaluation of each term of large constant logical expressions when determining their potentiality. PR c++/102780 gcc/cp/ChangeLog: * constexpr.c (potential_constant_expression_1) <case TRUTH_*_EXPR>: When tf_error isn't set, preemptively check potentiality of the second operand before performing trial evaluation of the first operand. (potential_constant_expression_1): When tf_error is set, first check potentiality quietly and return true if successful, otherwise proceed noisily to give errors. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/fold13.C: New test. gcc/cp/constexpr.c | 26 +++++++++++++++++++++----- gcc/testsuite/g++.dg/cpp1z/fold13.C | 29 +++++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 5 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp1z/fold13.C
next prev parent reply other threads:[~2022-02-13 8:47 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-02-11 21:45 [Bug c++/104507] New: " junk at sigpwr dot com 2022-02-11 21:51 ` [Bug c++/104507] " pinskia at gcc dot gnu.org 2022-02-11 21:53 ` [Bug c++/104507] [10/11 Regression] " pinskia at gcc dot gnu.org 2022-02-13 8:47 ` junk at sigpwr dot com [this message] 2022-02-13 23:03 ` pinskia at gcc dot gnu.org 2022-02-14 0:57 ` junk at sigpwr dot com 2022-02-14 8:32 ` rguenth at gcc dot gnu.org 2022-02-14 11:18 ` jakub at gcc dot gnu.org 2022-02-14 16:57 ` [Bug c++/104507] [10/11/12 " ppalka at gcc dot gnu.org 2022-02-15 16:17 ` ppalka at gcc dot gnu.org 2022-02-16 17:42 ` cvs-commit at gcc dot gnu.org 2022-02-16 17:43 ` [Bug c++/104507] [10/11 " ppalka at gcc dot gnu.org 2022-04-12 23:44 ` cvs-commit at gcc dot gnu.org 2022-05-04 0:22 ` [Bug c++/104507] [10 " ppalka at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-104507-4-nFjgWhTF5l@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).