The following invalid testcase triggers an ICE on the trunk: ============================================================ struct A { A(void* i=); A(void* i=); A(void* i=); void operator+ (void* i=); virtual void foo1(=); void foo2(=); void foo3(=); void foo4(=); void foo5(=); }; A::A (void* i=) {} ============================================================ bug.cc:4: error: 'A::A(void*)' cannot be overloaded bug.cc:3: error: with 'A::A(void*)' [...lots of errors removed...] bug.cc:16: error: default argument given for parameter 1 of 'A::A(void*)' bug.cc:3: error: after previous specification in 'A::A(void*)' bug.cc:16: internal compiler error: canonical types differ for identical types void (A::)(void*) and void (A::)(void*) Please submit a full bug report, [etc.] The testcase is a little fragile, it looks like some memory access is not OK.
Today I can't reproduce it. Do you?
I can still reproduce it with trunk from 2009-02-07 (updated after your comment). As mentioned before the testcase is a little fragile. Some weeks ago I had a much larger testcase (about 150 lines) which I couldn't reduce any further. To me this looks like some fishy memory access.
Ah, ok, it's i686...
Confirmed.
This latent bug is triggered by the part of revision 143157: --- Index: i386.c =================================================================== --- i386.c (revision 143154) +++ i386.c (working copy) @@ -22183,6 +22183,11 @@ ix86_init_mmx_sse_builtins (void) V8SI_type_node, V4SI_type_node, integer_type_node, NULL_TREE); + tree pv4di_type_node = build_pointer_type (V4DI_type_node); + tree void_ftype_pv4di_v4di + = build_function_type_list (void_type_node, + pv4di_type_node, V4DI_type_node, + NULL_TREE); tree v8sf_ftype_v8sf_v4sf_int = build_function_type_list (V8SF_type_node, V8SF_type_node, V4SF_type_node, --- This patch: Index: cp/decl.c =================================================================== --- cp/decl.c (revision 143157) +++ cp/decl.c (working copy) @@ -1549,6 +1549,7 @@ duplicate_decls (tree newdecl, tree oldd error ("after previous specification in %q+#D", olddecl); } + return error_mark_node; } } } works for me.
Created attachment 17346 [details] A patch
A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00432.html
Subject: Bug 39060 Author: hjl Date: Sun Mar 8 17:29:12 2009 New Revision: 144710 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144710 Log: gcc/cp/ 2009-03-08 H.J. Lu <hongjiu.lu@intel.com> PR c++/39060 * parser.c (cp_parser_late_parsing_default_args): Continue the loop when cp_parser_assignment_expression returns error_mark_node. gcc/testsuite/ 2009-03-08 H.J. Lu <hongjiu.lu@intel.com> PR c++/39060 * g++.dg/other/new1.C: Adjusted. * g++.dg/parse/crash40.C: Likewise. * g++.dg/parse/defarg12.C: Likewise. * g++.dg/template/error15.C: Likewise. * g++.dg/other/pr39060.C: New. Added: trunk/gcc/testsuite/g++.dg/other/pr39060.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/other/new1.C trunk/gcc/testsuite/g++.dg/parse/crash40.C trunk/gcc/testsuite/g++.dg/parse/defarg12.C trunk/gcc/testsuite/g++.dg/template/error15.C
Fixed.
>The testcase is a little fragile, it looks like some memory access is not OK. Looks like it is still not fixed in the end: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604748.html The patch which hit the problem just added unrelated builtins even.