A spurious syntax error is produced by the following: static const int zero = 0; std::cout << (std::pair<int, int>(int(zero), int(zero))) << std::endl; In contrast, static const int zero = 0; static const int zero_alias = 0; std::cout << (std::pair<int, int>(int(zero), int(zero_alias))) << std::endl; compiles correctly (assuming that there is an appropriate overload for operator<<). Section 8.2[2] states that The ambiguity arising from the similarity between a function-style cast and a type-id can occur in different contexts. The ambiguity appears as a choice between a function-style cast expression and a declaration of a type. The resolution is that any construct that could possibly be a type-id in its syntactic context shall be considered a type-id. In this case, 8.2[2] should not apply, since the syntactic context of the parenthesized expression does not permit the production: cast-expression :: ( type-id ) cast-expression However, in the first code excerpt, where the parenthesized expression would not be a valid type-id (because of the redefinition of the parameter name), the syntax error is apparently being triggered before the ambiguity resolution decides that type-id is not possible. In the second code excerpt, the parenthesize expression could contain a valid type-id, but ambiguity resolution rejects that possibility. --- Bug report generated as a result of http://stackoverflow.com/questions/14403946/adding-parenthesis-to-a-constructor-call-causes-duplicate-parameter-error-in-xlc/14404900#14404900
Created attachment 29214 [details] Test cases as described in bug
Reduced: struct T { T(int, int); }; int main() { static const int zero = 0; (T(int(zero), int(zero))); }
This is closely related to PR29234. In fact, the patch I'm working on, as linked from the latter, already fixes this bug too.
Author: paolo Date: Sat Nov 2 09:34:13 2013 New Revision: 204312 URL: http://gcc.gnu.org/viewcvs?rev=204312&root=gcc&view=rev Log: /cp 2013-11-02 Paolo Carlini <paolo.carlini@oracle.com> PR c++/29234 PR c++/56037 * parser.c (cp_parser_cast_expression): If we aren't looking at a cast-expression don't call cp_parser_type_id. (cp_parser_postfix_expression): Likewise for compound-literal. (cp_parser_tokens_start_cast_expression): Adjust. /testsuite 2013-11-02 Paolo Carlini <paolo.carlini@oracle.com> PR c++/29234 PR c++/56037 * g++.dg/parse/pr29234.C: New. * g++.dg/parse/pr56037.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/parse/pr29234.C trunk/gcc/testsuite/g++.dg/parse/pr56037.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
Fixed for 4.9.0.