[Bug c++/101715] New: compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[Bug c++/101715] New: compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[unlvsur at live dot com]

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

            Bug ID: 101715
           Summary: compiler ice when uses a GCC cross compiler to
                    canadian compile LLVM libc++
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 51236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51236&action=edit
noexcept crash??

libc++ defines _NOEXCEPT_ macro and crashes

[Bug c++/101715] compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you attach the preprocessed source?  It is most likely a known issue which
we just don't hit in our libstdc++.

[Bug c++/101715] compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[unlvsur at live dot com]

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

--- Comment #2 from cqwrteur <unlvsur at live dot com> ---
(In reply to Andrew Pinski from comment #1)
> Can you attach the preprocessed source?  It is most likely a known issue
> which we just don't hit in our libstdc++.

No problem

[Bug c++/101715] compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[unlvsur at live dot com]

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

--- Comment #3 from cqwrteur <unlvsur at live dot com> ---
Created attachment 51237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51237&action=edit
Proeprocess.txt

Preprocess file.

command.txt contains my compilation toggles and error messages.
preprocess.txt is the process file

[Bug c++/101715] compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I can reproduce the ICE on x86_64-linux-gnu with a slight modification to the
preprocessed source (changing size_t to be unsigned long).

[Bug c++/101715] compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reduced testcase:
template <typename g> struct gggg{};
template<class tt>
struct   ffff
{
    ffff& yyy(ffff&& __str) noexcept((gggg<tt>::value));
    ffff& assign(ffff&& __str) noexcept((gggg<tt>::value));
};
template <class tt> ffff<tt>& ffff<tt>::yyy(ffff&& __str)
noexcept((gggg<tt>::value)) {}

[Bug c++/101715] [11/12 Regression] compiler ice when uses a GCC cross compiler to canadian compile LLVM libc++

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2021-08-01
            Summary|compiler ice when uses a    |[11/12 Regression] compiler
                   |GCC cross compiler to       |ice when uses a GCC cross
                   |canadian compile LLVM       |compiler to canadian
                   |libc++                      |compile LLVM libc++
      Known to work|                            |11.1.0
      Known to fail|                            |11.2.0, 12.0

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Confirmed.

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types caused by r12-1824

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression] ICE with |[11/12 Regression] ICE with
                   |noexcept and canonical      |noexcept and canonical
                   |types differ for identical  |types differ for identical
                   |types                       |types caused by r12-1824
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #7 from H.J. Lu <hjl.tools at gmail dot com> ---
It is caused by r12-1824.

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types caused by r12-1824

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to H.J. Lu from comment #7)
> It is caused by r12-1824.

It can't be as it was not backported to GCC 11.

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types caused by r12-1824

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.3
           Priority|P3                          |P2
      Known to work|                            |10.3.1

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Bisection shows the ICE starts at r12-1822, which was backported as r11-8662

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 103078 has been marked as a duplicate of this bug. ***

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[marxin at gcc dot gnu.org]

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

--- Comment #11 from Martin Liška <marxin at gcc dot gnu.org> ---
@Marek: Can you please take a look?

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

--- Comment #12 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
OK, I'd totally forgotten about this PR.

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |slyfox at gcc dot gnu.org

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 103279 has been marked as a duplicate of this bug. ***

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pjfloyd at wanadoo dot fr

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 103516 has been marked as a duplicate of this bug. ***

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[slyfox at gcc dot gnu.org]

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

--- Comment #15 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
clang's compiler-rt fails to build for quite a while due to this ICE.

Trying to poke at the failure. I shrunk the example slightly further:

  template <class A> struct S {
    S<A> & bar() noexcept(A::value);
    S<A> & foo() noexcept(A::value);
  };

  template <class A> S<A> & S<A>::foo() noexcept(A::value) {}

c++17 seems to be the trigger (perhaps due to noexcept argument type change?).
Also, if we comment out seemingly unrelated `S::foo()` declaration ICE
disappears. Could it be that there is an unexpected type sharing in an
uninstantiated type?

The backtrace:

$ g++-12.0.0 -c a.c.cpp -std=c++14
$ g++-12.0.0 -c a.c.cpp -std=c++17
a.c.cpp:6:56: internal compiler error: canonical types differ for identical
types 'S<A>& (S<A>::)() noexcept (A::value)' and 'S<A>& (S<A>::)() noexcept
(A::value)'
    6 | template <class A> S<A> & S<A>::foo() noexcept(A::value) {}
      |                                                        ^
0xc3f6ee comptypes(tree_node*, tree_node*, int)
        ../../gcc-12-20211226/gcc/cp/typeck.c:1558
0xa784ce duplicate_decls(tree_node*, tree_node*, bool, bool)
        ../../gcc-12-20211226/gcc/cp/decl.c:2409
0xa7f2bb grokfndecl
        ../../gcc-12-20211226/gcc/cp/decl.c:10351
0xa83cf6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
        ../../gcc-12-20211226/gcc/cp/decl.c:14154
0xa88196 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
        ../../gcc-12-20211226/gcc/cp/decl.c:17171
0xb82c0f cp_parser_function_definition_from_specifiers_and_declarator
        ../../gcc-12-20211226/gcc/cp/parser.c:31047
0xb82c0f cp_parser_init_declarator
        ../../gcc-12-20211226/gcc/cp/parser.c:22520
0xb8a93e cp_parser_single_declaration
        ../../gcc-12-20211226/gcc/cp/parser.c:31683
0xb8aab6 cp_parser_template_declaration_after_parameters
        ../../gcc-12-20211226/gcc/cp/parser.c:31243
0xb8b340 cp_parser_explicit_template_declaration
        ../../gcc-12-20211226/gcc/cp/parser.c:31509
0xb8dcf1 cp_parser_declaration
        ../../gcc-12-20211226/gcc/cp/parser.c:14849
0xb8e7a2 cp_parser_toplevel_declaration
        ../../gcc-12-20211226/gcc/cp/parser.c:14939
0xb8e7a2 cp_parser_translation_unit
        ../../gcc-12-20211226/gcc/cp/parser.c:4987
0xb8e7a2 c_parse_file()
        ../../gcc-12-20211226/gcc/cp/parser.c:47944
0xcbefcd c_common_parse_file()
        ../../gcc-12-20211226/gcc/c-family/c-opts.c:1238
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.

Poking at the internals:

(gdb) fr 1
#1  0x0000000000c3f6ef in comptypes (t1=0x7fffea3791f8, t2=0x7fffea3627e0,
strict=<optimized out>) at ../../gcc-12-20211226/gcc/cp/typeck.c:1557
1557    ../../gcc-12-20211226/gcc/cp/typeck.c: No such file or directory.
(gdb) call debug_generic_expr(t1)
struct S & S::<T385> (struct S *)
(gdb) call debug_generic_expr(t2)
struct S & S::<T37d> (struct S *)

(gdb) call debug_tree(t1)
 <method_type 0x7fffea3791f8
    type <reference_type 0x7fffea3629d8
        type <record_type 0x7fffea362930 S cxx-odr-p type_0 type_5 type_6 VOID
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362c78 context <translation_unit_decl 0x7fffea220168 a.c.cpp>
            full-name "struct S<A>"
            no-binfo use_template=1 interface-unknown
            reference_to_this <reference_type 0x7fffea3629d8> chain <type_decl
0x7fffea241b48 S>>
        unsigned DI
        size <integer_cst 0x7fffea212f48 constant 64>
        unit-size <integer_cst 0x7fffea212f60 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362f18>
    QI
    size <integer_cst 0x7fffea234048 type <integer_type 0x7fffea2320a8
bitsizetype> constant 8>
    unit-size <integer_cst 0x7fffea234060 type <integer_type 0x7fffea232000
sizetype> constant 1>
    align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea3627e0 method basetype <record_type 0x7fffea362c78 S>
    arg-types <tree_list 0x7fffea378438
        value <pointer_type 0x7fffea362dc8 type <record_type 0x7fffea362c78 S>
            unsigned DI size <integer_cst 0x7fffea212f48 64> unit-size
<integer_cst 0x7fffea212f60 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362dc8>
        chain <tree_list 0x7fffea228b68 value <void_type 0x7fffea232f18 void>>>
    throws <tree_list 0x7fffea378410
        purpose <scope_ref 0x7fffea3783e8 tree_0 arg:0 <template_type_parm
0x7fffea362888 A>
            arg:1 <identifier_node 0x7fffea22e4c0 value
                normal local bindings <(nil)>>
            a.c.cpp:6:51 start: a.c.cpp:6:51 finish: a.c.cpp:6:55>>>

(gdb) call debug_tree(t2)
 <method_type 0x7fffea3627e0
    type <reference_type 0x7fffea362f18
        type <record_type 0x7fffea362c78 S cxx-odr-p type_0 type_5 type_6 VOID
            size <integer_cst 0x7fffea212fc0 constant 0>
            unit-size <integer_cst 0x7fffea212f78 constant 0>
            align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362c78 fields <using_decl 0x7fffea241a18 operator=> context
<translation_unit_decl 0x7fffea220168 a.c.cpp>
            full-name "struct S<A>"
            n_parents=0 use_template=0 interface-unknown
            pointer_to_this <pointer_type 0x7fffea362dc8> reference_to_this
<reference_type 0x7fffea362f18> chain <type_decl 0x7fffea2418e8 S>>
        unsigned type_0 type_6 DI
        size <integer_cst 0x7fffea212f48 constant 64>
        unit-size <integer_cst 0x7fffea212f60 constant 8>
        align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362f18>
    type_0 type_6 QI
    size <integer_cst 0x7fffea234048 type <integer_type 0x7fffea2320a8
bitsizetype> constant 8>
    unit-size <integer_cst 0x7fffea234060 type <integer_type 0x7fffea232000
sizetype> constant 1>
    align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362540 method basetype <record_type 0x7fffea362c78 S>
    arg-types <tree_list 0x7fffea35cf28
        value <pointer_type 0x7fffea362dc8 type <record_type 0x7fffea362c78 S>
            unsigned DI size <integer_cst 0x7fffea212f48 64> unit-size
<integer_cst 0x7fffea212f60 8>
            align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffea362dc8>
        chain <tree_list 0x7fffea228b68 value <void_type 0x7fffea232f18 void>>>
    throws <tree_list 0x7fffea378230
        purpose <scope_ref 0x7fffea378208 tree_0 arg:0 <template_type_parm
0x7fffea362bd0 A>
            arg:1 <identifier_node 0x7fffea22e4c0 value
                normal local bindings <(nil)>>
            a.c.cpp:3:30 start: a.c.cpp:3:30 finish: a.c.cpp:3:34>>>

If I read the difference correctly `t1` has no `operator=` field while `t2`
has.

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

--- Comment #16 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
This slightly modified test started to ICE with r11-4682 which is the gist of
the problem:

template <class T> struct S {
  S<T> bar() noexcept(T::value);
  S<T> foo() noexcept(T::value);
};

template <class T> S<T> S<T>::foo() noexcept(T::value) {}

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch

--- Comment #17 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Patch posted
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588520.html

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[slyfox at gcc dot gnu.org]

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

--- Comment #18 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #17)
> Patch posted
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588520.html

Applying patch locally fixes build of compiler-rt from llvm-13 for me. Thank
you!

[Bug c++/101715] [11/12 Regression] ICE with noexcept and canonical types differ for identical types

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:3abcbf243239f9576a60f4ce7f8ee4b3fa14784b

commit r12-6802-g3abcbf243239f9576a60f4ce7f8ee4b3fa14784b
Author: Marek Polacek <polacek@redhat.com>
Date:   Fri Jan 14 17:41:49 2022 -0500

    c++: ICE with noexcept and canonical types [PR101715]

    This is a "canonical types differ for identical types" ICE, which started
    with r11-4682.  It's a bit tricky to explain.  Consider:

      template <typename T> struct S {
        S<T> bar() noexcept(T::value);  // #1
        S<T> foo() noexcept(T::value);  // #2
      };

      template <typename T> S<T> S<T>::foo() noexcept(T::value) {}  // #3

    We ICE because #3 and #2 have the same type, but their canonical types
    differ: TYPE_CANONICAL (#3) == #2 but TYPE_CANONICAL (#2) == #1.

    The member functions #1 and #2 have the same type.  However, since their
    noexcept-specifier is deferred, when parsing them, we create a variant for
    both of them, because DEFERRED_PARSE cannot be compared.  In other words,
    build_cp_fntype_variant's

      tree v = TYPE_MAIN_VARIANT (type);
      for (; v; v = TYPE_NEXT_VARIANT (v))
        if (cp_check_qualified_type (v, type, type_quals, rqual, raises, late))
          return v;

    will *not* find an existing variant when creating a method_type for #2, so
we
    have to create a new one.

    But then we perform delayed parsing and call
fixup_deferred_exception_variants
    for #1 and #2.  f_d_e_v will replace TYPE_RAISES_EXCEPTIONS with the newly
    parsed noexcept-specifier.  It also sets TYPE_CANONICAL (#2) to #1.  Both
    noexcepts turned out to be the same, so now we have two equivalent variants
in
    the list!  I.e.,

    +-----------------+      +-----------------+      +-----------------+
    |      main       |      |      #2         |      |      #1         |
    | S S::<T379>(S*) |----->| S S::<T37c>(S*) |----->| S S::<T37a>(S*)
|----->NULL
    |    -            |      |  noex(T::value) |      |  noex(T::value) |
    +-----------------+      +-----------------+      +-----------------+

    Then we get to #3.  As for #1 and #2, grokdeclarator calls
build_memfn_type,
    which ends up calling build_cp_fntype_variant, which will use the loop
    above to look for an existing variant.  The first one that matches
    cp_check_qualified_type will be used, so we use #2 rather than #1, and the
    TYPE_CANONICAL mismatch follows.  Hopefully that makes sense.

    As for the fix, I didn't think I could rewrite the method_type #2 with #1
    because the type may have escaped via decltype.  So my approach is to
    elide #2 from the list, so when looking for a matching variant, we always
    find #1 (#2 remains live though, which admittedly sounds sort of dodgy).

            PR c++/101715

    gcc/cp/ChangeLog:

            * tree.cc (fixup_deferred_exception_variants): Remove duplicate
            variants after parsing the exception specifications.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/noexcept72.C: New test.
            * g++.dg/cpp0x/noexcept73.C: New test.

[Bug c++/101715] [11 Regression] ICE with noexcept and canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[11/12 Regression] ICE with |[11 Regression] ICE with
                   |noexcept and canonical      |noexcept and canonical
                   |types differ for identical  |types differ for identical
                   |types                       |types

--- Comment #20 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed on trunk so far.

[Bug c++/101715] [11 Regression] ICE with noexcept and canonical types differ for identical types

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Marek Polacek
<mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:9f2201bf48e828a7072616fff9dbd64367dcea30

commit r11-9508-g9f2201bf48e828a7072616fff9dbd64367dcea30
Author: Marek Polacek <polacek@redhat.com>
Date:   Mon Jan 24 16:24:47 2022 -0500

    c++: ICE with noexcept and canonical types [PR101715]

    This is a "canonical types differ for identical types" ICE, which started
    with r11-4682.  It's a bit tricky to explain.  Consider:

      template <typename T> struct S {
        S<T> bar() noexcept(T::value);  // #1
        S<T> foo() noexcept(T::value);  // #2
      };

      template <typename T> S<T> S<T>::foo() noexcept(T::value) {}  // #3

    We ICE because #3 and #2 have the same type, but their canonical types
    differ: TYPE_CANONICAL (#3) == #2 but TYPE_CANONICAL (#2) == #1.

    The member functions #1 and #2 have the same type.  However, since their
    noexcept-specifier is deferred, when parsing them, we create a variant for
    both of them, because DEFERRED_PARSE cannot be compared.  In other words,
    build_cp_fntype_variant's

      tree v = TYPE_MAIN_VARIANT (type);
      for (; v; v = TYPE_NEXT_VARIANT (v))
        if (cp_check_qualified_type (v, type, type_quals, rqual, raises, late))
          return v;

    will *not* find an existing variant when creating a method_type for #2, so
we
    have to create a new one.

    But then we perform delayed parsing and call
fixup_deferred_exception_variants
    for #1 and #2.  f_d_e_v will replace TYPE_RAISES_EXCEPTIONS with the newly
    parsed noexcept-specifier.  It also sets TYPE_CANONICAL (#2) to #1.  Both
    noexcepts turned out to be the same, so now we have two equivalent variants
in
    the list!  I.e.,

    +-----------------+      +-----------------+      +-----------------+
    |      main       |      |      #2         |      |      #1         |
    | S S::<T379>(S*) |----->| S S::<T37c>(S*) |----->| S S::<T37a>(S*)
|----->NULL
    |    -            |      |  noex(T::value) |      |  noex(T::value) |
    +-----------------+      +-----------------+      +-----------------+

    Then we get to #3.  As for #1 and #2, grokdeclarator calls
build_memfn_type,
    which ends up calling build_cp_fntype_variant, which will use the loop
    above to look for an existing variant.  The first one that matches
    cp_check_qualified_type will be used, so we use #2 rather than #1, and the
    TYPE_CANONICAL mismatch follows.  Hopefully that makes sense.

    As for the fix, I didn't think I could rewrite the method_type #2 with #1
    because the type may have escaped via decltype.  So my approach is to
    elide #2 from the list, so when looking for a matching variant, we always
    find #1 (#2 remains live though, which admittedly sounds sort of dodgy).

            PR c++/101715

    gcc/cp/ChangeLog:

            * tree.c (fixup_deferred_exception_variants): Remove duplicate
            variants after parsing the exception specifications.

    gcc/testsuite/ChangeLog:

            * g++.dg/cpp0x/noexcept72.C: New test.
            * g++.dg/cpp0x/noexcept73.C: New test.

    (cherry picked from commit 3abcbf243239f9576a60f4ce7f8ee4b3fa14784b)

[Bug c++/101715] [11 Regression] ICE with noexcept and canonical types differ for identical types

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #22 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Fixed.