This code ICEs. This isn't preprocessed but is trivial and the preprocessor lines highlight a change that switches the ICE on and off so I've left it in to help. ***************************************** template<typename A, typename B> struct pair; template<typename... T> struct pairs; template<typename... AS, typename... BS> struct pairs<pair<AS, BS>...> { #ifndef NO_ICE struct mismatched_packs {}; #endif }; template class pairs< pair<int, int>, pair<int, int> >; ***************************************** Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ./configure --enable-languages=c++ Thread model: posix gcc version 4.4.0 20080712 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-std=c++0x' '-shared-libgcc' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -E -quiet -v -D_GNU_SOURCE fail.cc -mtune=generic -std=c++0x -O3 -fpch-preprocess -o fail.ii ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/x86_64-unknown-linux-gnu /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../include/c++/4.4.0/backward /usr/local/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-c' '-std=c++0x' '-shared-libgcc' '-mtune=generic' /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus -fpreprocessed fail.ii -quiet -dumpbase fail.cc -mtune=generic -auxbase fail -O3 -std=c++0x -version -o fail.s GNU C++ (GCC) version 4.4.0 20080712 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080712 (experimental), GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: f6a0a74a0d4d0fcd1077c2c18ac6908a fail.cc: In instantiation of ‘pairs<pair<int, int>, pair<int, int> >’: fail.cc:14: instantiated from here fail.cc:10: error: mismatched argument pack lengths while expanding ‘pair<AS, BS>’ fail.cc: In instantiation of ‘pairs<pair<int, int>, pair<int, int> >::mismatched_packs’: fail.cc:14: instantiated from here fail.cc:10: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in instantiate_class_template, at cp/pt.c:6945 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions.
> fail.cc: In instantiation of ‘pairs<pair<int, int>, pair<int, int> >’: > fail.cc:14: instantiated from here > fail.cc:10: error: mismatched argument pack lengths while expanding ‘pair<AS, > BS>’ > fail.cc: In instantiation of ‘pairs<pair<int, int>, pair<int, int> > >::mismatched_packs’: > fail.cc:14: instantiated from here > fail.cc:10: internal compiler error: tree check: expected class ‘type’, have > ‘exceptional’ (error_mark) in instantiate_class_template, at cp/pt.c:6945 4.3.1 doesn't ICE (I can't get details as somebody was kind enough to try this for me) and instead reports: t.cpp:10: error: mismatched argument pack lengths while expanding ‘pair<AS, BS>‘ t.cpp:10: error: mismatched argument pack lengths while expanding ‘pair<AS, BS>‘ where the ICE is reported above with -DNO_ICE this is compiled successfully
Created attachment 16124 [details] ice when NO_ICE is not defined This is the same source as in my original report but as an attachment.
Ping since this is a regression and has not yet been triaged.
I'm not sure whether the code snippet is really valid or not, but I can confirm the ICE nevertheless. GCC 4.3.x already crashed, you probably need --enable-checking to see the ICE. It's a regression, because the compiler crashes even without the -std=gnu++0x switch.
valid or not? If so then it's a rejects-valid, otherwise it is error-recovery.
Subject: Re: [4.3/4.4 regression] ICE with variadic templates partial specialization On Sat, 2009-01-03 at 15:26 +0000, rguenth at gcc dot gnu dot org wrote: > > ------- Comment #5 from rguenth at gcc dot gnu dot org 2009-01-03 15:26 ------- > valid or not? If so then it's a rejects-valid, otherwise it is error-recovery. I had discussed these c++0x features in ##c++ and I came to the conclusion that it was valid code. But I'm not an expert in c++0x, I discovered this problem while experimenting when learning. It accepts the code without the nested struct, it is only with a nested struct that the code is rejected. I don't think a nested struct will make it invalid and the behaviour of ambiguity analysis with a larger example suggests the code is very carefully and consciously accepted without that struct - agreeing with my studies and conversations on IRC.
Subject: Bug 36846 Author: jason Date: Wed Jan 7 20:43:01 2009 New Revision: 143166 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143166 Log: PR c++/35297 PR c++/35477 PR c++/35784 PR c++/36846 PR c++/38276 * pt.c (check_default_tmpl_args): Don't complain about out-of-order parameter packs in the enclosing class or parameter packs after default args. (coerce_template_parms): If we have more than one parameter pack, don't flatten argument packs. (template_args_equal): Handle argument packs. (comp_template_args): Don't flatten argument packs. (check_instantiated_arg): Split out from... (check_instantiated_args): Here. Handle arg packs. (convert_template_argument): Just check that nontype argument packs have the right type. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic92.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic93.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/variadic65.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic82.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic83.C
Fixed.