[Bug c++/12291] [3.4 regression?] filename only sometimes in mangled name of anonymous namespace members

["phil dot el at wanadoo dot fr" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12291



------- Additional Comments From phil dot el at wanadoo dot fr  2003-09-16 00:39 -------
Subject: Re:  regression in anonymous namespace variable name
 mangling

bangerth at dealii dot org wrote:
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12291
> 
> 
> bangerth at dealii dot org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|WAITING                     |NEW
>      Ever Confirmed|                            |1
>    Last reconfirmed|0000-00-00 00:00:00         |2003-09-15 23:37:02
>                date|                            |
> 
> 
> ------- Additional Comments From bangerth at dealii dot org  2003-09-15 23:37 -------
> A very odd failure, indeed. Consider the following code:
> --------------------------
> struct S {
>     int foo() const;
> };
> 
> void bar(const S& s) { s.foo(); }
> 
> struct X {
>     int foo () const { return S().foo(); }
> };
> 
> namespace { int option_array; }
> --------------------------
> 
> Compiled with present mainline, I get the following result:
> g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c y.cc
> g/x> nm y.o | grep option_array
> 00000000 B _ZN21_GLOBAL__N__Z3barRK1S12option_arrayE
> 
> There's indeed no trace of the filename in the mangled name. Now, comment
> out the unrelated function bar():

this one is right: since bar is defined and get an external linkage
using the name bar in the mangled name ensure than the mangled name
is unique (except if the user violate the ODR and g++ don't care about
that because ODR violation is undefined behavior)

> -------------------------
> struct S {
>     int foo() const;
> };
> 
> //void bar(const S& s) { s.foo(); }
> 
> struct X {
>     int foo () const { return S().foo(); }
> };
> 
> namespace { int option_array; }
> ---------------------------
> 
> g/x> /home/bangerth/bin/gcc-3.4-pre/bin/c++ -c y.cc
> g/x> nm y.o | grep option_array
> 00000000 B _ZN33_GLOBAL__N_y.cc_FCBB6B6F_09E9D69B12option_arrayE
> 
> Ups -- the filename is back. What's going on here?

this one is right too: there is no unique name in this compilation
unit the compiler can use to uniquify the mangled name so it fallback
to use the filename and a 64 pseudo-random value.

> 
> I can see this behavior going all the way back to gcc2.95, so this
> is not a recent regression.

nope the recent regression is shown only by the original test.
As you saw compiler older than 15 days mangle the filename
which is right but nowaday the compiler "thinks" than _M_dataEv
is an unique name in all possible compilation unit and use it
to mangle the name but this assumption is wrong.

Note as I said it occur only when the compiler see a
"extern template class basic_string<char>;" in libstdc++
header, I removed in preprocessed output and gcc is no
longer confused and use the filename in the mangled name

phe