This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
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.
Keith
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
| OPERATOR ARROW
{ $$ = make_operator ("->", 2); }
| OPERATOR '(' ')'
- { $$ = make_operator ("()", 0); }
+ { $$ = make_operator ("()", 2); }
| OPERATOR '[' ']'
{ $$ = make_operator ("[]", 2); }
;