The following (IMHO valid) code snippet triggers an ICE on mainline: ================================================== int x[5]; template<int M, int N, int (&... p)[N]> struct A; template<int M> struct A<M,5,x> {}; A<0,5,x> a; ================================================== bug.cc:7: internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:8528 Please submit a full bug report, [etc.]
This isn't a regression, variadic templates were added on 20070209 and this fails with a compiler from 20070210.
(In reply to comment #1) > This isn't a regression, variadic templates were added on 20070209 and this > fails with a compiler from 20070210. Well the ICE itself is a regression. So the regression marker is used for the follow cases: rejects-valid -> ICE accepts-invalid -> ICE works -> ICE works -> wrong code works -> wrong warning And some other cases
In fact at some point I'd like to open a discussion about what we consider a *regression*. I mean, *regression* means to me, roughly, "something used to work and now all of a sudden doesn't work anymore, we must quickly fix it!". However, we mark PRs as [4.1/4.2/4.3 regression], and that very often means something different! Because we often mark like that issues which date back to 3.4 or even 3.3! And that because we want only to mention active branches. Overall, I think this approach may be very confusing. Another, smaller, issue is that in case of ICEs on invalid should be more clear from the PR whether it happens only in development builds, or not: the latter are definitely less serious, IMO, at least now that we have "confused by earlier errors..."
(In reply to comment #3) > Another, smaller, issue is that in case of ICEs on invalid should be > more clear from the PR whether it > happens only in development builds, or not: the latter are definitely less > serious, IMO, at least now that we have "confused by earlier errors..." We do, that is the error-recovery keyword comes into play. Hmm, this bug is also an error recovery issue anyways (with the default settings) so marking it as such.
Subject: Bug 32252 Author: dgregor Date: Tue Oct 30 13:36:34 2007 New Revision: 129773 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=129773 Log: 2007-10-30 Douglas Gregor <doug.gregor@gmail.com> PR c++/31993 PR c++/32252 * pt.c (find_parameter_packs_r): Fix typo in comment. (convert_template_argument): Look at the pattern of a pack expansion to determine what kind of entity we're converting. (coerce_template_parameter_pack): When we have coerced a non-type template parameter pack, substitute into the type of that pack. (tsubst_pack_expansion): When our substitution of a parameter pack is a "trivial" substitution of itself, just substitute into the pack expansion rather than actually expanding. 2007-10-30 Douglas Gregor <doug.gregor@gmail.com> PR c++/31993 PR c++/32252 * g++.dg/cpp0x/pr31993.C: New * g++.dg/cpp0x/pr32252.C: New Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr31993.C trunk/gcc/testsuite/g++.dg/cpp0x/pr32252.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/parse/crash36.C
Fixed.