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++/108998] [12 Regression] ICE in tsubst, at cp/pt.cc:16037
Date: Tue, 07 Mar 2023 02:18:36 +0000	[thread overview]
Message-ID: <bug-108998-4-U03Fr1slPg@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-108998-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108998

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Patrick Palka
<ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:c0edd2060dbc5aad0bae3ef4d68c8e85f26d0062

commit r12-9231-gc0edd2060dbc5aad0bae3ef4d68c8e85f26d0062
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Mar 3 11:37:02 2023 -0500

    c++: thinko in extract_local_specs [PR108998]

    In order to fix PR100295, r13-4730-g18499b9f848707 attempted to make
    extract_local_specs walk the given pattern twice, ignoring unevaluated
    operands the first time around so that we prefer to process a local
    specialization in an evaluated context if it appears in one (we process
    each local specialization once even if it appears multiple times in the
    pattern).

    But there's a thinko in the patch, namely that we don't actually walk
    the pattern twice since we don't clear the visited set for the second
    walk (to avoid processing a local specialization twice) and so the root
    node (and any node leading up to an unevaluated operand) is considered
    visited already.  So the patch effectively made extract_local_specs
    ignore unevaluated operands altogether, which this testcase demonstrates
    isn't quite safe (extract_local_specs never sees 'aa' and we don't record
    its local specialization, so later we try to specialize 'aa' on the spot
    with the args {{int},{17}} which causes us to nonsensically substitute
    its auto with 17.)

    This patch fixes this by refining the second walk to start from the
    trees we skipped over during the first walk.

            PR c++/108998

    gcc/cp/ChangeLog:

            * pt.cc (el_data::skipped_trees): New data member.
            (extract_locals_r): Push to skipped_trees any unevaluated
            contexts that we skipped over.
            (extract_local_specs): For the second walk, start from each
            tree in skipped_trees.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp2a/lambda-generic11.C: New test.

    (cherry picked from commit 341e6cd8d603a334fd34657a6b454176be1c6437)

  parent reply	other threads:[~2023-03-07  2:18 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-02 23:54 [Bug c++/108998] New: " waffl3x at protonmail dot com
2023-03-03  0:03 ` [Bug c++/108998] " waffl3x at protonmail dot com
2023-03-03  0:06 ` [Bug c++/108998] [13 Regression] " mpolacek at gcc dot gnu.org
2023-03-03  0:07 ` waffl3x at protonmail dot com
2023-03-03 14:09 ` ppalka at gcc dot gnu.org
2023-03-03 15:14 ` [Bug c++/108998] [12/13 " ppalka at gcc dot gnu.org
2023-03-03 16:37 ` cvs-commit at gcc dot gnu.org
2023-03-03 16:39 ` [Bug c++/108998] [12 " ppalka at gcc dot gnu.org
2023-03-07  2:18 ` cvs-commit at gcc dot gnu.org [this message]
2023-03-07  2:21 ` ppalka at gcc dot gnu.org
2023-05-22  3:12 ` cvs-commit 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-108998-4-U03Fr1slPg@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: link
Be 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).