[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

["hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>]

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