From: Michael Elizabeth Chastain <mec@shout.net>
To: binutils@sources.redhat.com, hjl@lucon.org
Cc: gdb@sources.redhat.com
Subject: Re: FYI: A new C++ demangler
Date: Fri, 11 Jul 2003 00:36:00 -0000 [thread overview]
Message-ID: <200307110036.h6B0aZCI016995@duracef.shout.net> (raw)
Summary: no regressions in the gdb test suite. One change detected
that's a slight improvement.
I know this is moot because gdb can't use code implemented in C++,
but I thought it would be interesting to run the test anyways.
I tested this with the usual:
target => native
host => i686-pc-linux-gnu
osversion => red-hat-8.0
gdb => HEAD%20030708
gcc => 2.95.3, 3.2-7-rh, 3.3, gcc-3_3-branch%20030707, HEAD%20030707
binutils => 2.13.90.0.2-rh, 2.14, binutils-2_14-branch%20030707, HEAD%20030707
glibc => 2.2.93-5-rh
gformat => dwarf-2, stabs+
glevel => 2
All the gcc v2 results were unchanged (obviously, since gdb still uses the
same v2 demangler).
The gcc v3 results were the same for all versions of gcc v3,
binutils, and gformat. There were three places where something like
this happened:
# old
print &'dm_type_unsigned_int'
$6 = (int (*)(unsigned int)) 0x8048940 <dm_type_unsigned_int(unsigned)>
(gdb) PASS: gdb.c++/cplusfuncs.exp: detect dm_type_unsigned_int
# new
print &'dm_type_unsigned_int'
$6 = (int (*)(unsigned int)) 0x8048940 <dm_type_unsigned_int(unsigned int)>
(gdb) PASS: gdb.c++/cplusfuncs.exp: detect dm_type_unsigned_int
That is, the old demangler prints 'unsigned' in some places, and the new
demangler prints 'unsigned int'. This happened once in
gdb.c++/cplusfuncs.exp and twice in gdb.c++/templates.exp.
Michael C
next reply other threads:[~2003-07-11 0:36 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-07-11 0:36 Michael Elizabeth Chastain [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-07-12 18:02 Nathanael Nerode
2003-07-15 16:17 ` Andrew Cagney
2003-07-15 18:03 ` Gabriel Dos Reis
2003-07-15 19:02 ` Andrew Cagney
2003-07-15 19:03 ` Alexandre Oliva
2003-07-15 19:16 ` H. J. Lu
2003-07-15 19:49 ` Alexandre Oliva
2003-07-15 19:55 ` H. J. Lu
2003-07-15 22:30 ` Alexandre Oliva
2003-07-15 23:14 ` H. J. Lu
2003-07-16 2:31 ` Alexandre Oliva
2003-07-16 3:21 ` Ian Lance Taylor
2003-07-16 17:12 ` Nathanael Nerode
2003-07-15 19:16 ` Ian Lance Taylor
2003-07-15 19:23 ` H. J. Lu
2003-07-15 20:05 ` DJ Delorie
2003-07-10 21:57 Michael Elizabeth Chastain
2003-07-10 15:42 Michael Elizabeth Chastain
2003-07-10 15:51 ` H. J. Lu
2003-07-10 16:38 ` Ian Lance Taylor
2003-07-10 14:36 H. J. Lu
2003-07-10 14:40 ` Ian Lance Taylor
2003-07-10 14:54 ` H. J. Lu
2003-07-10 15:28 ` David Carlton
2003-07-10 15:36 ` H. J. Lu
2003-07-10 15:44 ` David Carlton
2003-07-10 20:57 ` Mark Kettenis
2003-07-10 21:17 ` Andrew Cagney
2003-07-10 21:44 ` H. J. Lu
2003-07-10 22:58 ` Frank Ch. Eigler
2003-07-10 23:19 ` Andrew Cagney
2003-07-10 21:22 ` DJ Delorie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200307110036.h6B0aZCI016995@duracef.shout.net \
--to=mec@shout.net \
--cc=binutils@sources.redhat.com \
--cc=gdb@sources.redhat.com \
--cc=hjl@lucon.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox