[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added CC||andi-gcc at firstfloor dot ||org --- Comment #16 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-19 00:00:47 UTC --- *** Bug 50783 has been marked as a duplicate of this bug. ***
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #17 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-19 00:01:54 UTC --- (In reply to comment #13) It would be nice to fix it in binutils and in gdb as well. libiberty should be merged automatically ...
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
--- Comment #14 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26
18:29:52 UTC ---
Author: ccoutant
Date: Mon Sep 26 18:29:46 2011
New Revision: 179209
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179209
Log:
include/ChangeLog:
PR 40831
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_CLONE.
libiberty/ChangeLog:
PR 40831
* cp-demangle.c (d_make_comp): Add new component type.
(cplus_demangle_mangled_name): Check for clone suffixes.
(d_parmlist): Don't error out if we see '.'.
(d_clone_suffix): New function.
(d_print_comp): Print info for clone suffixes.
* testsuite/demangle-expected: Add new testcases.
Modified:
branches/gcc-4_6-branch/ (props changed)
branches/gcc-4_6-branch/include/ChangeLog
branches/gcc-4_6-branch/include/demangle.h
branches/gcc-4_6-branch/libiberty/ChangeLog
branches/gcc-4_6-branch/libiberty/cp-demangle.c
branches/gcc-4_6-branch/libiberty/testsuite/demangle-expected
Propchange: branches/gcc-4_6-branch/
('svn:mergeinfo' added)
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #15 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-26 18:33:38 UTC --- Fixed on trunk and in gcc-4_6-branch.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #13 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-09-24 10:39:28 UTC --- Thanks! It would be nice to fix it in binutils and in gdb as well.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #12 from Cary Coutant ccoutant at gcc dot gnu.org 2011-09-23 21:39:13 UTC --- Author: ccoutant Date: Fri Sep 23 21:39:10 2011 New Revision: 179132 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=179132 Log: include/ChangeLog: PR 40831 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CLONE. libiberty/ChangeLog: PR 40831 * cp-demangle.c (d_make_comp): Add new component type. (cplus_demangle_mangled_name): Check for clone suffixes. (d_parmlist): Don't error out if we see '.'. (d_clone_suffix): New function. (d_print_comp): Print info for clone suffixes. * testsuite/demangle-expected: Add new testcases. Modified: trunk/include/ChangeLog trunk/include/demangle.h trunk/libiberty/ChangeLog trunk/libiberty/cp-demangle.c trunk/libiberty/testsuite/demangle-expected
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added Attachment #23439|0 |1 is obsolete|| --- Comment #11 from Cary Coutant ccoutant at gcc dot gnu.org 2011-08-20 00:54:56 UTC --- Created attachment 25060 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25060 Updated patch to demangle cloned function symbols This patch generalizes the clone suffix recognition, so it accepts a series of suffixes of the form [.clonetype][.nnn]
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #9 from Cary Coutant ccoutant at gcc dot gnu.org 2011-02-23 18:30:19 UTC --- Does not work for `_Z3fooi.1988' or `_Z3fooi.part.9.165493.constprop.775.31805'. Where does the _Z3fooi.1988 style come from? I guess your second example is from a cloned function (due to partial inlining) that got cloned again (due to constant propagation), but why are there two numbers on each?
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
--- Comment #10 from Jan Hubicka hubicka at ucw dot cz 2011-02-23 19:03:36
UTC ---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
--- Comment #9 from Cary Coutant ccoutant at gcc dot gnu.org 2011-02-23
18:30:19 UTC ---
Does not work for `_Z3fooi.1988' or
`_Z3fooi.part.9.165493.constprop.775.31805'.
Where does the _Z3fooi.1988 style come from?
We add the .1234 suffixes in LTO for local symbols (to avoid clashes in between
two static
variables of the same name).
As WHOPR progress, we might end up adding two numbered suffixes, because we
mangle at wpa time and then ship the mangled symbols to ltrans when we mangle
again. Disabling the second mangling is trivial, but no one did it yet. The
first mangling happens even when tere are no conflicts that is stupid, but in
case of conflicts it needs to happen.
I guess your second example is from a cloned function (due to partial
inlining)
that got cloned again (due to constant propagation), but why are there two
numbers on each?
_Z3fooi.1988 is created from _Z3fooi by LTO mangling.
We also do precisely same mangling from function static variables, i.e.
test()
{
static int a;
}
will get out a as a.1234
_Z3fooi becomes _Z3fooi.part.9 by partial inlining
.165493 is added at WPA time because function is static (all partial functions
are)
.constprop.775 is added because one of argument was proved to be constant by
cprop pass
.31805 comes from (completely redundant) name mangling at ltrans time.
It is possible to change way we mangle the LTO vars, if neccesary for some good
reason.
Those numbered suffixes that do not come from function versioning (i.e. don't
have .part or .constprop) are redundant, so I guess they might be just silently
dropped?
Honza
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Cary Coutant ccoutant at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |ccoutant at gcc dot gnu.org |gnu.org | --- Comment #7 from Cary Coutant ccoutant at gcc dot gnu.org 2011-02-23 02:00:08 UTC --- Created attachment 23439 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23439 Patch to add demangler support for cloned function symbols include/ChangeLog: PR 40831 * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_CLONE, DEMANGLE_COMPONENT_CONSTPROP_CLONE, DEMANGLE_COMPONENT_ISRA_CLONE, DEMANGLE_COMPONENT_PART_CLONE. libiberty/ChangeLog: PR 40831 * cp-demangle.c (struct clone_suffix_list): New type. (d_make_comp): Add new component types. (cplus_demangle_mangled_name): Check for clone suffixes. (d_parmlist): Don't error out if we see '.'. (clone_suffixes): New array. (d_clone_suffix): New function. (d_print_comp): Print info for clone suffixes. * testsuite/demangle-expected: Add new testcases.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 --- Comment #8 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-02-23 07:53:45 UTC --- Does not work for `_Z3fooi.1988' or `_Z3fooi.part.9.165493.constprop.775.31805'.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.06 14:07:31 CC||dj at redhat dot com, ||hubicka at gcc dot gnu.org, ||ian at airs dot com Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #6 from Jan Hubicka hubicka at gcc dot gnu.org 2011-01-06 14:07:31 UTC --- We certainly can improve libiberty demangler to handle the cloning suffixes. It would not hurt and is certainly nice thing to have. I am not terribly familiar with demnagler implementation so I would preffer someone else to do it. Concerning question how _ZN1C3fooEi.isra.0. should be demangled, I think we already use english sentences for some functions names like static constructor keyed to XYZ, so probably we can go C::foo(int) isra clone 0 or we even can go further and expand the abbrebiated names GCC use for different types of clones. For most of purposes however the tools should use debug info that contains the correct link back to original function... Marking as enhancement request and adding our libiberty maintainers into CC.
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added CC||d.g.gorbachev at gmail dot ||com --- Comment #5 from Dmitry Gorbachev d.g.gorbachev at gmail dot com 2011-01-05 01:07:00 UTC --- There's also a binutils bug http://sourceware.org/PR12337: Programs objdump, nm, addr2line, c++filt, gprof, do not demangle cloned function names, such as _ZN1C3fooEi.isra.0. Could be C::foo.isra.0(int) or C::foo(int).isra.0 (?)
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
--- Comment #1 from cgd at google dot com 2009-07-22 23:29 --- Created an attachment (id=18239) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18239action=view) example c++ input that shows creation of a cloned function which isn't demangled. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-22 23:35 --- I don't see a problem with this really since it is a local symbol and will never be exported so the ABI never gets involved. a demangled name is only a nice way of displaying the name to the user rather than anything else. The profiles and other tools could figure out if it has .clone.n to strip that and then add it back. User generated symbols will never have .clone.n in it unless asm is used. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-22 23:36 --- Also by the way 4.4.0 and before generated just T.N which is even worse than the current behavior. demangle symbols according to the ABI an What is an ABI for a local symbol? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
[Bug c++/40831] g++ generated symbols for cloned function that be demangled.
--- Comment #4 from cgd at google dot com 2009-07-22 23:44 --- (In reply to comment #2) I don't see a problem with this really since it is a local symbol and will never be exported so the ABI never gets involved. a demangled name is only a nice way of displaying the name to the user rather than anything else. The profiles and other tools could figure out if it has .clone.n to strip that and then add it back. User generated symbols will never have .clone.n in it unless asm is used. I could buy your argument, I'm just not quite sure yet. If this is reasonable output from the compiler, then people will need to take action (e.g., enhance the debugger, and enhance any tools they care about). I think output from 'nm' are a good first example case. What do *you* (or others) think is appropriate output from 'nm' in this example? (IIRC binutils uses the gcc-supplied demangler, right?) Do you have guidance for how functions like these should be presented by other tools, e.g., gdb? BTW, I definitely agree that the current behavior is much more useful than T.. 8-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
