public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/100295] Internal compiler error from generic lambda capturing parameter pack and expanding it in if constexpr Date: Mon, 22 May 2023 03:12:22 +0000 [thread overview] Message-ID: <bug-100295-4-4UAcJcw2hy@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-100295-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100295 --- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-11 branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>: https://gcc.gnu.org/g:58d2a4cdbbafa4431eb9cff3778099d185f9f391 commit r11-10804-g58d2a4cdbbafa4431eb9cff3778099d185f9f391 Author: Patrick Palka <ppalka@redhat.com> Date: Thu Dec 15 16:02:05 2022 -0500 c++: extract_local_specs and unevaluated contexts [PR100295] Here during partial instantiation of the constexpr if, extra_local_specs walks the statement looking for local specializations within to capture. However, we're thwarted by the fact that 'ts' first appears inside an unevaluated context, and so the calls to process_outer_var_ref for its local specializations are a no-op. And since we walk each tree exactly once, we end up not capturing the local specializations despite 'ts' later occurring in an evaluated context. This patch fixes this by making extract_local_specs walk evaluated contexts first before walking unevaluated contexts. We could probably get away with not walking unevaluated contexts at all, but this approach seems more clearly safe. PR c++/100295 PR c++/107579 gcc/cp/ChangeLog: * pt.c (el_data::skip_unevaluated_operands): New data member. (extract_locals_r): If skip_unevaluated_operands is true, don't walk into unevaluated contexts. (extract_local_specs): Walk the pattern twice, first with skip_unevaluated_operands true followed by it set to false. gcc/testsuite/ChangeLog: * g++.dg/cpp1z/constexpr-if-lambda5.C: New test. (cherry picked from commit 18499b9f848707aee42d810e99ac0a4c9788433c)
next prev parent reply other threads:[~2023-05-22 3:12 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-27 18:44 [Bug c++/100295] New: " davidfromonline at gmail dot com 2021-04-28 12:30 ` [Bug c++/100295] " ppalka at gcc dot gnu.org 2021-10-21 4:21 ` pinskia at gcc dot gnu.org 2021-10-21 4:22 ` pinskia at gcc dot gnu.org 2022-08-24 1:50 ` pinskia at gcc dot gnu.org 2022-12-03 9:08 ` pinskia at gcc dot gnu.org 2022-12-15 21:03 ` cvs-commit at gcc dot gnu.org 2022-12-15 21:04 ` ppalka at gcc dot gnu.org 2022-12-19 16:54 ` cvs-commit at gcc dot gnu.org 2023-02-17 13:24 ` ppalka at gcc dot gnu.org 2023-05-22 3:12 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-22 3:15 ` 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-100295-4-4UAcJcw2hy@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).