[Bug c++/94632] New: [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[Bug c++/94632] New: [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[marxin at gcc dot gnu.org]

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

            Bug ID: 94632
           Summary: [10 Regression] canonical types differ for identical
                    types since r10-7622-g12f55e030ed068d5
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: marxin at gcc dot gnu.org
                CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

It affects the build of libqt5-qtwebengine package:

$ cat wtf.ii
template <typename> struct a;
template <bool> struct b;
template <typename> class c {
  template <typename f> void d(f e, typename b<a<decltype(e)>::h>::g);
public:
  static bool h;
};
bool h = c<int>::h;

$ g++ wtf.ii -c
wtf.ii: In instantiation of ‘class c<int>’:
wtf.ii:8:16:   required from here
wtf.ii:4:30: internal compiler error: canonical types differ for identical
types ‘b<a<decltype (e)>::h>’ and ‘b<a<decltype (e)>::h>’
    4 |   template <typename f> void d(f e, typename b<a<decltype(e)>::h>::g);
      |                              ^
0xb29f7d comptypes(tree_node*, tree_node*, int)
        /home/marxin/Programming/gcc/gcc/cp/typeck.c:1519
0xb299d4 structural_comptypes
        /home/marxin/Programming/gcc/gcc/cp/typeck.c:1410
0xace7ba maybe_rebuild_function_decl_type
        /home/marxin/Programming/gcc/gcc/cp/pt.c:13541
0xace7ba tsubst_function_decl
        /home/marxin/Programming/gcc/gcc/cp/pt.c:13778
0xad0c90 tsubst_template_decl
        /home/marxin/Programming/gcc/gcc/cp/pt.c:14018
0xab94ee tsubst_decl
        /home/marxin/Programming/gcc/gcc/cp/pt.c:14140
0xac2ef7 tsubst(tree_node*, tree_node*, int, tree_node*)
        /home/marxin/Programming/gcc/gcc/cp/pt.c:15026
0xade994 instantiate_class_template_1
        /home/marxin/Programming/gcc/gcc/cp/pt.c:11728
0xade994 instantiate_class_template(tree_node*)
        /home/marxin/Programming/gcc/gcc/cp/pt.c:12036
0xb2579d complete_type(tree_node*)
        /home/marxin/Programming/gcc/gcc/cp/typeck.c:137
0xa76193 cp_parser_nested_name_specifier_opt
        /home/marxin/Programming/gcc/gcc/cp/parser.c:6639
0xa7302e cp_parser_simple_type_specifier
        /home/marxin/Programming/gcc/gcc/cp/parser.c:18126
0xa744e7 cp_parser_postfix_expression
        /home/marxin/Programming/gcc/gcc/cp/parser.c:7173
0xa7d28f cp_parser_unary_expression
        /home/marxin/Programming/gcc/gcc/cp/parser.c:8560
0xa5421f cp_parser_cast_expression
        /home/marxin/Programming/gcc/gcc/cp/parser.c:9451
0xa54a59 cp_parser_binary_expression
        /home/marxin/Programming/gcc/gcc/cp/parser.c:9554
0xa564de cp_parser_assignment_expression
        /home/marxin/Programming/gcc/gcc/cp/parser.c:9859
0xa5548d cp_parser_constant_expression
        /home/marxin/Programming/gcc/gcc/cp/parser.c:10153
0xa55a51 cp_parser_initializer_clause
        /home/marxin/Programming/gcc/gcc/cp/parser.c:23216
0xa59cc7 cp_parser_initializer
        /home/marxin/Programming/gcc/gcc/cp/parser.c:23154
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
      Known to work|                            |9.3.0
   Last reconfirmed|                            |2020-04-17
   Target Milestone|---                         |10.0
      Known to fail|                            |10.0
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P1

[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Looking into it.

[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Smaller testcase that exhibits the ICE:

template <bool> struct b;
template <typename> class c {
  template <typename f> static void d(f e, b<decltype(e)::k> x);
public:
  static const bool h = false;
};
bool y = c<int>::h;

[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[cvs-commit at gcc dot gnu.org]

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

--- 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>:

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

commit r10-7787-gf83adb68ed9cef1fbd4c16447eb4e89676df9f62
Author: Patrick Palka <ppalka@redhat.com>
Date:   Sat Apr 18 06:22:21 2020 -0400

    c++: spec_hasher::equal and PARM_DECLs [PR94632]

    In the testcase below, during specialization of c<int>::d, we build two
    identical specializations of the parameter type b<decltype(e)::k> -- one
when
    substituting into c<int>::d's TYPE_ARG_TYPES and another when substituting
into
    c<int>::d's DECL_ARGUMENTS.

    We don't reuse the first specialization the second time around as a
consequence
    of the fix for PR c++/56247 which made PARM_DECLs always compare different
from
    one another during spec_hasher::equal.  As a result, when looking up
existing
    specializations of 'b', spec_hasher::equal considers the template argument
    decltype(e')::k to be different from decltype(e'')::k, where e' and e'' are
the
    result of two calls to tsubst_copy on the PARM_DECL e.

    Since the two specializations are considered different due to the mentioned
fix,
    their TYPE_CANONICAL points to themselves even though they are otherwise
    identical types, and this triggers an ICE in
maybe_rebuild_function_decl_type
    when comparing the TYPE_ARG_TYPES of c<int>::d to its DECL_ARGUMENTS.

    This patch fixes this issue at the spec_hasher::equal level by ignoring the
    'comparing_specializations' flag in cp_tree_equal whenever the
DECL_CONTEXTs of
    the two parameters are identical.  This seems to be a sufficient condition
to be
    able to correctly compare PARM_DECLs structurally.  (This also subsumes the
    CONSTRAINT_VAR_P check since constraint variables all have empty, and
therefore
    identical, DECL_CONTEXTs.)

    gcc/cp/ChangeLog:

            PR c++/94632
            * tree.c (cp_tree_equal) <case PARM_DECL>: Ignore
            comparing_specializations if the parameters' contexts are
identical.

    gcc/testsuite/ChangeLog:

            PR c++/94632
            * g++.dg/template/canon-type-14.C: New test.

[Bug c++/94632] [10 Regression] canonical types differ for identical types since r10-7622-g12f55e030ed068d5

[ppalka at gcc dot gnu.org]

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED

--- Comment #4 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Fixed.