| Summary: | [4.3 regression] ICE with specialization of variadic template | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Volker Reichelt <reichelt> |
| Component: | c++ | Assignee: | dgregor |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | doug.gregor, fang, gcc-bugs |
| Priority: | P2 | Keywords: | ice-on-valid-code, monitored |
| Version: | 4.3.0 | ||
| Target Milestone: | 4.3.0 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2007-12-15 08:29:12 | |
| Attachments: | gcc43-pr32565.patch | ||
Created attachment 14255 [details] gcc43-pr32565.patch WIP patch to fix this. As shown in the testcase, I believe trying to handle ARGUMENT_PACK_P (parm) && !ARGUMENT_PACK_P (arg) in unify in unify is bad, as parm may need more than one argument. So IMHO this has to be handled one level higher where we have access to all the arguments. I don't know what exactly to do with argument packs which have PACK_EXPANSION_P at the end (can you come up with a testcase for that) and especially if such ARGUMENT_PACK_P is not the last template argument (that is only possible for function templates, right)? Confirmed. Subject: Bug 32565 Author: dgregor Date: Tue Dec 18 21:19:41 2007 New Revision: 131041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131041 Log: 2007-12-18 Douglas Gregor <doug.gregor@gmail.com> Jakub Jelinek <jakub@redhat.com> PR c++/32565 PR c++/33943 PR c++/33965 * pt.c (template_template_parm_bindings_ok_p): New; verifies bindings of template template parameters after all template arguments have been deduced. (coerce_template_parms): Don't complain when COMPLAIN doesn't include tf_error. (fn_type_unification): Use template_template_parm_bindings_ok_p. (unify): Deal with variadic, bound template template parameters. (get_class_bindings): Use template_template_parm_bindings_ok_p. 2007-12-18 Douglas Gregor <doug.gregor@gmail.com> Jakub Jelinek <jakub@redhat.com> PR c++/32565 PR c++/33943 PR c++/33965 * g++.dg/cpp0x/variadic86.C: New. * g++.dg/cpp0x/variadic87.C: New. * g++.dg/cpp0x/variadic84.C: New. * g++.dg/cpp0x/variadic85.C: New. * g++.dg/template/ttp25.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic84.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic85.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic86.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic87.C trunk/gcc/testsuite/g++.dg/template/ttp25.C Modified: trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog Fixed on the trunk |
The following valid code snippet triggers an ICE on mainline: ============================================================ template<typename...> struct A; template<template<int...> class T> struct A<T<0> > {}; template<int> struct B; A<B<0> > a; ============================================================ bug.cc:7: internal compiler error: tree check: expected class 'expression', have 'constant' (integer_cst) in unify, at cp/pt.c:12796 Please submit a full bug report, [etc.] A similar testcase generates a slightly different error message: ============================================================ template<typename...> struct A; template<template<typename...> class T> struct A<T<int> > {}; template<typename> struct B; A<B<int> > a; ============================================================ bug.cc:7: internal compiler error: tree check: expected class 'expression', have 'type' (integer_type) in unify, at cp/pt.c:12796 Please submit a full bug report, [etc.]