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++/99833] [8/9/10 Regression] structured binding + if init + generic lambda = internal compiler error Date: Tue, 20 Apr 2021 09:46:19 +0000 [thread overview] Message-ID: <bug-99833-4-yoMwZ5cDdk@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-99833-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99833 --- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-10 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:06d50ebc9fb2761ed2bdda5e76adb4d47a8ca983 commit r10-9728-g06d50ebc9fb2761ed2bdda5e76adb4d47a8ca983 Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Apr 16 09:32:44 2021 +0200 c++: Fix up handling of structured bindings in extract_locals_r [PR99833] The following testcase ICEs in tsubst_decomp_names because the assumptions that the structured binding artificial var is followed in DECL_CHAIN by the corresponding structured binding vars is violated. I've tracked it to extract_locals* which is done for the constexpr IF_STMT. extract_locals_r when it sees a DECL_EXPR adds that decl into a hash set so that such decls aren't returned from extract_locals*, but in the case of a structured binding that just means the artificial var and not the vars corresponding to structured binding identifiers. The following patch fixes it by pushing not just the artificial var for structured bindings but also the other vars. 2021-04-16 Jakub Jelinek <jakub@redhat.com> PR c++/99833 * pt.c (extract_locals_r): When handling DECL_EXPR of a structured binding, add to data.internal also all corresponding structured binding decls. * g++.dg/cpp1z/pr99833.C: New test. * g++.dg/cpp2a/pr99833.C: New test. (cherry picked from commit 20eb7a1891cfd7fa85295a236cebe0322d041edd)
next prev parent reply other threads:[~2021-04-20 9:46 UTC|newest] Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-03-30 17:17 [Bug c++/99833] New: " nickgray0 at brown dot edu 2021-03-30 20:24 ` [Bug c++/99833] [8/9/10/11 Regression] " mpolacek at gcc dot gnu.org 2021-03-30 20:57 ` mpolacek at gcc dot gnu.org 2021-03-30 20:58 ` mpolacek at gcc dot gnu.org 2021-03-30 21:28 ` ppalka at gcc dot gnu.org 2021-03-31 7:56 ` rguenth at gcc dot gnu.org 2021-03-31 17:24 ` ppalka at gcc dot gnu.org 2021-04-14 9:40 ` jakub at gcc dot gnu.org 2021-04-14 9:54 ` jakub at gcc dot gnu.org 2021-04-14 10:36 ` jakub at gcc dot gnu.org 2021-04-14 11:14 ` jakub at gcc dot gnu.org 2021-04-14 12:25 ` ppalka at gcc dot gnu.org 2021-04-16 7:33 ` cvs-commit at gcc dot gnu.org 2021-04-16 7:35 ` [Bug c++/99833] [8/9/10 " jakub at gcc dot gnu.org 2021-04-20 9:46 ` cvs-commit at gcc dot gnu.org [this message] 2021-04-20 9:53 ` [Bug c++/99833] [8/9 " jakub at gcc dot gnu.org 2021-04-20 23:34 ` cvs-commit at gcc dot gnu.org 2021-04-22 16:53 ` cvs-commit at gcc dot gnu.org 2021-04-22 17:11 ` jakub 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-99833-4-yoMwZ5cDdk@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).