Compiled with -std=c++0x, version g++ (GCC) 4.3.0 20070921 (experimental), the following program causes an ICE. {{{ template<typename... A> struct foo {}; template<typename A0, typename... A1> struct bar {}; template<typename U> struct baz; template<template<typename...> class T, typename... U> struct baz< T<U...> > {}; template<template<typename, typename...> class T, typename U, typename... V> struct baz< T<U, V...> > {}; baz< foo<int, short> > b1; baz< bar<int, short> > b2; }}}
Confirmed, the ICE is an error recovery regression.
Mark, this is really only an error recovery regression. Can you relook at the current priority? Thanks, Andrew Pinski
This is valid code, so it's more serious than we thought.
The code is still invalid C++98 so the regression is still just an error recovery issue :).
I disagree with Andrew's Comment #4. Once we implement a feature in the compiler, users should reasonably expect it to be correct. We cannot simultaneously say "Look, we have exciting new C++0x features!" and "Oh, you found a bug? That's not very serious, since it's just a new C++0x feature." Thus, I've upgraded this to P1.
(In reply to comment #5) > I disagree with Andrew's Comment #4. Once we implement a feature in the > compiler, users should reasonably expect it to be correct. We cannot > simultaneously say "Look, we have exciting new C++0x features!" and "Oh, you > found a bug? That's not very serious, since it's just a new C++0x feature." I seriously disagree, this is not a regression in that code never was supported before and really C++0x support should not block the release just because people feel this is an important feature of 4.3.0. Also another thing is that we have some ODR violations in libstdc++ that the libstdc++ folks have not replied to me about yet. See http://gcc.gnu.org/ml/libstdc++/2007-08/msg00032.html and some others.
(In reply to comment #6) Also another thing is that > we have some ODR violations in libstdc++ that the libstdc++ folks have not > replied to me about yet. Because such a thing doesn't exist. If the user wants to experiment (note, experiment, we are talking about experimental implementations, I think the announcement is pretty clear about that) with some library features that will be likely available in the next C++ standard, he can compile with -std=c++0x. Then he will be in the realm of another language, not the same as C++03. ODR between what? Between a language and a different (eminently experimental) language? By the way, the real library for the next standard will be something very different (we haven't yet started on it), will badly break ABI, API and everything imaginable.
Subject: Bug 33943 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