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++/100102] [9/10/11/12 Regression] ICE in tsubst, at cp/pt.c:15310
Date: Mon, 07 Jun 2021 22:37:46 +0000	[thread overview]
Message-ID: <bug-100102-4-TFfd7J45AD@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-100102-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #23 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:f1feb74046e0feb0596b93bbb822fae02940a90e

commit r11-8520-gf1feb74046e0feb0596b93bbb822fae02940a90e
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Jun 4 13:46:53 2021 -0400

    c++: tsubst_function_decl and excess arg levels [PR100102]

    Here, when instantiating the dependent alias template
    duration::__is_harmonic with args={{T,U},{int}}, we find ourselves
    substituting the function decl _S_gcd.  Since we have more arg levels
    than _S_gcd has parm levels, an old special case in tsubst_function_decl
    causes us to unwantedly reduce args to its innermost level, yielding
    args={int}, which leads to a nonsensical substitution into the decl
    context and eventually a crash.

    The comment for this special case refers to three examples for which we
    ought to see more arg levels than parm levels here, but none of the
    examples actually demonstrate this.  In the first example, when
    defining S<int>::f(U) parms_depth is 2 and args_depth is 1, and
    later when instantiating say S<int>::f<char> both depths are 2.  In the
    second example, when substituting the template friend declaration
    parms_depth is 2 and args_depth is 1, and later when instantiating f
    both depths are 1.  Finally, the third example is invalid since we can't
    specialize a member template of an unspecialized class template like
    that.

    Given that this reduction code seems no longer relevant for its
    documented purpose and that it causes problems as in the PR, this patch
    just removes it.  Note that as far as bootstrap/regtest is concerned,
    this code is dead; the below two tests would be the first to reach it.

            PR c++/100102

    gcc/cp/ChangeLog:

            * pt.c (tsubst_function_decl): Remove old code for reducing
            args when it has excess levels.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/alias-decl-72.C: New test.
            * g++.dg/cpp0x/alias-decl-72a.C: New test.

    (cherry picked from commit 5357ab75dedef403b0eebf9277d61d1cbeb5898f)

  parent reply	other threads:[~2021-06-07 22:37 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-15 16:03 [Bug tree-optimization/100102] New: " schnetter at gmail dot com
2021-04-15 16:05 ` [Bug tree-optimization/100102] " schnetter at gmail dot com
2021-04-15 17:37 ` jakub at gcc dot gnu.org
2021-04-15 17:41 ` [Bug tree-optimization/100102] [8/9/10/11 Regression] " jakub at gcc dot gnu.org
2021-04-15 18:13 ` jakub at gcc dot gnu.org
2021-04-16  6:57 ` rguenth at gcc dot gnu.org
2021-04-16 13:01 ` schnetter at gmail dot com
2021-04-28  1:26 ` [Bug tree-optimization/100102] [8/9/10/11/12 " ed.gcc at pobox dot com
2021-04-28 12:05 ` [Bug c++/100102] " ppalka at gcc dot gnu.org
2021-04-28 14:56 ` taraba.peter at mail dot com
2021-05-14  9:54 ` [Bug c++/100102] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:20 ` rguenth at gcc dot gnu.org
2021-06-03 16:50 ` redi at gcc dot gnu.org
2021-06-03 16:52 ` redi at gcc dot gnu.org
2021-06-03 16:53 ` redi at gcc dot gnu.org
2021-06-03 16:55 ` redi at gcc dot gnu.org
2021-06-03 17:02 ` redi at gcc dot gnu.org
2021-06-03 23:14 ` ppalka at gcc dot gnu.org
2021-06-04  2:32 ` ppalka at gcc dot gnu.org
2021-06-04  3:50 ` ppalka at gcc dot gnu.org
2021-06-04 17:47 ` cvs-commit at gcc dot gnu.org
2021-06-04 21:44 ` ed.gcc at pobox dot com
2021-06-07 14:22 ` ppalka at gcc dot gnu.org
2021-06-07 22:37 ` cvs-commit at gcc dot gnu.org [this message]
2021-06-07 22:54 ` cvs-commit at gcc dot gnu.org
2021-06-07 22:56 ` [Bug c++/100102] [9 " ppalka at gcc dot gnu.org
2021-06-08  3:55 ` cvs-commit at gcc dot gnu.org
2021-11-03 18:38 ` ppalka at gcc dot gnu.org
2021-12-02 19:20 ` 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-100102-4-TFfd7J45AD@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).