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
