This is the mail archive of the mailing list for the Archer project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merging fun again

Jan Kratochvil wrote:
Still it has a regression against FSF GDB (+Rawhide) on:
FAIL: gdb.cp/cplusfuncs.exp: print &'foo::operator()(foo&)'
(I did not investigate it more if it is expected from some other branch.)

If the merge or python branches are carrying Daniel's string canonicalization for C++ (cp_canonicalize_string), this failure could be a result of a disagreement between libiberty and cp-name-parser.y.

Somewhere in the lookup chain, a check is done on libiberty's cplus_demangle_operators array. This is an array of structures with three elements, and the comparison that is done not only compares the name of the operator, but all three members of this structure. For operator(), libiberty specifies the "args" member of this structure as 2 and cp-name-parser.y supplies 0. As a result, operator() is never matched.

Try this simple patch and see if this fixes the problem. It had no regressions on my sandbox.

diff --git a/gdb/cp-name-parser.y b/gdb/cp-name-parser.y
index e1641f4..f599fd5 100644
--- a/gdb/cp-name-parser.y
+++ b/gdb/cp-name-parser.y
@@ -1,6 +1,6 @@
 /* YACC parser for C++ names, for GDB.
-   Copyright (C) 2003, 2004, 2005, 2007, 2008 Free Software Foundation, Inc.
+   Copyright (C) 2003, 2004, 2005, 2007, 2008, 2009 Free Software Foundation, Inc.
    Parts of the lexer are based on c-exp.y from GDB.
@@ -499,7 +499,7 @@ operator	:	OPERATOR NEW
 			{ $$ = make_operator ("->", 2); }
 		|	OPERATOR '(' ')'
-			{ $$ = make_operator ("()", 0); }
+			{ $$ = make_operator ("()", 2); }
 		|	OPERATOR '[' ']'
 			{ $$ = make_operator ("[]", 2); }

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]