[Bug c++/107539] [13 Regression] ICE, same canonical type node for different types with decltype inside an generic lambda inside a templated method of a templated class using a templated class argument since r13-737-gd0ef9e06197d14d7

cvs-commit at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Dec 2 01:12:25 GMT 2022


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

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

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

commit r13-4453-ga4e577b044d69977f93b2cb7769dc991eadf2cf0
Author: Patrick Palka <ppalka@redhat.com>
Date:   Thu Dec 1 20:11:53 2022 -0500

    c++: comptypes ICE with BOUND_TEMPLATE_TEMPLATE_PARMs [PR107539]

    Here we end up giving the two BOUND_TEMPLATE_TEMPLATE_PARMs
    C<decltype(f::t)> and C<decltype(g::t)> the same TYPE_CANONICAL because
    the hash table that interns TYPE_CANONICAL for template type parameters
    doesn't set the comparing_specializations flag which controls how
    PARM_DECLs from different contexts compare equal.

    Later, from spec_hasher::equal for the corresponding two specializations
    A<C<decltype(f::t)>> and A<C<decltype(g::t)>>, we compare the two bound
    ttps with comparing_specializations set hence they now (structurally)
    compare different despite having the same TYPE_CANONICAL, and so we get
    the error:

      internal compiler error: same canonical type node for different types
        'C<decltype (t)>' and 'C<decltype (t)>'

    This suggests that we should be setting comparing_specializations from
    ctp_hasher::equal to match spec_hasher::equal.  But doing so introduces
    a separate ICE in cpp2a/concepts-placeholder3.C:

      internal compiler error: canonical types differ for identical types
        'auto [requires ::same_as<<placeholder>, decltype(f::x)>]' and
        'auto [requires ::same_as<<placeholder>, decltype(g::x)>]'

    because norm_hasher::equal doesn't set comparing_specializations either.

    I'm not sure when exactly we need to set comparing_specializations given
    what it controls (TYPENAME_TYPE equality/hashing and PARM_DECL equality)
    but it seems to be the conservative choice to set the flag wherever we
    have a global hash table that relies on type equality.  To that end this
    patch sets comparing_specializations in ctp_hasher and norm_hasher, as
    well as in atom_hasher and sat_hasher for good measure.  This turns out
    to be a compile time win of about 2% in some concepts tests, probably
    because of the improved TYPENAME_TYPE hashing enabled by the flag.

            PR c++/107539

    gcc/cp/ChangeLog:

            * constraint.cc (norm_hasher::hash, norm_hasher::equal): Set
            comparing_specializations.
            (sat_hasher::hash, sat_hasher::equal): Likewise.
            * cp-tree.h (atom_hasher::hash, atom_hasher::equal): Likewise.
            * pt.cc (ctp_hasher::hash, ctp_hasher::equal): Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/template/canon-type-19.C: New test.


More information about the Gcc-bugs mailing list