The following valid code snippet triggers an ICE on mainline: ===================== void foo(long ...); ===================== bug.cc:1: internal compiler error: Segmentation fault Please submit a full bug report, [etc.] The same thing happens for the following invalid variation: ===================== void foo(const ...); =====================
I guess this is also related to your patch for variadic templates, Douglas, but I might be wrong: 2007-03-09 Douglas Gregor <doug.gregor@gmail.com> PR c++/20599 * typeck.c (check_return_expr): Check for bare parameter packs. (comptypes): Compare template parameter packs and type pack expansions. ...
How is the first one valid? I thought you always needed a comma before the ellipsis for variable argument functions (I know in C you need it for sure).
In C++ the comma before ... is optional. Where syntactically correct, “, ...” is synonymous with “...”.
Patch here: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00799.html
*** Bug 31372 has been marked as a duplicate of this bug. ***
Subject: Bug 31138 Author: dgregor Date: Sat Mar 31 13:41:30 2007 New Revision: 123380 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=123380 Log: 2007-03-31 Douglas Gregor <doug.gregor@gmail.com> PR c++/31138 PR c++/31140 PR c++/31141 * parser.c (declarator_can_be_parameter_pack): New. (cp_parser_template_parameter): Only parse the `...' if the declarator can be a parameter pack. (cp_parser_parameter_declaration): Ditto. Also, handle when TYPE is NULL. * pt.c (find_parameter_packs_r): Look into the bounds on integer types (they could be used as array bounds). (check_for_bare_parameter_packs): Deal with TEMPLATE_PARM_INDEX. (tsubst_pack_expansion): Handle failure to expand parameter packs. 2007-03-31 Douglas Gregor <doug.gregor@gmail.com> * g++.dg/parser/pr31138.C: New. * g++.dg/parser/pr31140.C: New. * g++.dg/parser/pr31141.C: New. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
Fixed in mainline compiler