[Bug c++/105797] [11/12/13 Regression] Internal compiler error: Segmentation fault ( fn_type_unification -> satisfaction_cache::satisfaction_cache -> iterative_hash_template_arg )

cvs-commit at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Fri Jun 3 13:09:15 GMT 2022


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


commit r13-980-gdf4f95dbd4764ffc1e8270e5b3c0fd71b6724562
Author: Patrick Palka <ppalka@redhat.com>
Date:   Fri Jun 3 09:08:41 2022 -0400

    c++: find_template_parameters and PARM_DECLs [PR105797]

    As explained in r11-4959-gde6f64f9556ae3, the atom cache assumes two
    equivalent expressions (according to cp_tree_equal) must use the same
    template parameters (according to find_template_parameters).  This
    assumption turned out to not hold for TARGET_EXPR, which was addressed
    by that commit.

    But this assumption apparently doesn't hold for PARM_DECL either:
    find_template_parameters walks its DECL_CONTEXT but cp_tree_equal by
    default doesn't consider DECL_CONTEXT unless comparing_specializations
    is set.  Thus in the first testcase below, the atomic constraints of #1
    and #2 are equivalent according to cp_tree_equal, but according to
    find_template_parameters the former uses T and the latter uses both T
    and U (surprisingly).

    We could fix this assumption violation by setting comparing_specializations
    in the atom_hasher, which would make cp_tree_equal return false for the
    two atoms, but that seems overly pessimistic here.  Ideally the atoms
    should continue being considered equivalent and we instead fix
    find_template_paremeters to return just T for #2's atom.

    To that end this patch makes for_each_template_parm_r stop walking the
    DECL_CONTEXT of a PARM_DECL.  This should be safe to do because
    tsubst_copy / tsubst_decl only substitutes the TREE_TYPE of a PARM_DECL
    and doesn't bother substituting the DECL_CONTEXT, thus the only relevant
    template parameters are those used in its type.  any_template_parm_r is
    currently responsible for walking its TREE_TYPE, but I suppose it now makes
    sense for for_each_template_parm_r to do so instead.

    In passing this patch also makes for_each_template_parm_r stop walking
    the DECL_CONTEXT of a VAR_/FUNCTION_DECL since doing so after walking
    DECL_TI_ARGS is redundant, I think.

    I experimented with not walking DECL_CONTEXT for CONST_DECL, but the
    second testcase below demonstrates it's necessary to walk it.

            PR c++/105797


            * pt.cc (for_each_template_parm_r) <case FUNCTION_DECL, VAR_DECL>:
            Don't walk DECL_CONTEXT.
            <case PARM_DECL>: Likewise.  Walk TREE_TYPE.
            <case CONST_DECL>: Simplify.
            (any_template_parm_r) <case PARM_DECL>: Don't walk TREE_TYPE.


            * g++.dg/cpp2a/concepts-decltype4.C: New test.
            * g++.dg/cpp2a/concepts-memfun3.C: New test.

More information about the Gcc-bugs mailing list