Bug 28065

Summary: [4.2.0] filename no longer encoded in certain mangled symbol names
Product: gcc Reporter: Thomas Pintaric <pintaric>
Component: regressionAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: major CC: bangerth, debian-gcc, gcc-bugs, mark, pinskia, pintaric, tbm
Priority: P3    
Version: 4.2.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:

Description Thomas Pintaric 2006-06-16 18:34:43 UTC
I ran into a problem using Boost C++ (CVS HEAD 2006-06-16) with gcc 4.2.0
20060610 (and newer). Basically, filenames are not longer encoded in
the mangled name of certain symbols (possibly related to anonymous namespaces?),
though they should be. Since the issue did not occur with gcc
4.2.0 20060603, it should be relatively easy to track down (?).

TEST CASE:
-------------------------------------------------------
test1.cpp:
0001  #include <boost/numeric/ublas/functional.hpp>
0002  int main(int argc, char* argv[]) {}
-------------------------------------------------------
test2.cpp:
0001  #include <boost/numeric/ublas/functional.hpp>
-------------------------------------------------------

[gcc 4.2.0-20060602] - COMPILES
> > /opt/gcc/4.2.0-20060602/bin/g++ test1.cpp test2.cpp -I/../boost

[gcc 4.2.0-20060615] - FAILS
> > /opt/gcc/4.2.0-20060615/bin/g++ test1.cpp test2.cpp -I/../boost

/tmp/ccrmBhTq.o:(.data+0x0): multiple definition of
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
/tmp/cc63Tw4q.o:(.data+0x0): first defined here
collect2: ld returned 1 exit status

=======================================================
after removing main() from test1.cpp ...

-------------------------------------------------------
test1b.cpp:
0001  #include <boost/numeric/ublas/functional.hpp>
-------------------------------------------------------
test2b.cpp:
0001  #include <boost/numeric/ublas/functional.hpp>
-------------------------------------------------------

> > /opt/gcc/4.2.0-20060602/bin/g++ -c test1b.cpp test2b.cpp -I/../boost
> > nm test1b.o > test1b.txt
> > nm test2b.o > test2b.txt
> > diff test1b.txt test2b.txt

3c3
< 0000014c t _GLOBAL__I_test1b.cpp_8D2A3925_7FEB930D
---
> > 0000014c t _GLOBAL__I_test2b.cpp_8D2A3925_E969CAE1


> > nm test1b.o

         U __cxa_atexit
         U __dso_handle
0000014c t _GLOBAL__I_test1b.cpp_8D2A3925_DD2AD2D0
         U __gxx_personality_v0
00000168 t __tcf_0
0000010c t _Z41__static_initialization_and_destruction_0ii
         U _ZNKSs4sizeEv
         U _ZNKSsixEj
         U _ZNSt8ios_base4InitC1Ev
         U _ZNSt8ios_base4InitD1Ev
00000000 t _ZSt17__verify_groupingPKcjRKSs
00000000 W _ZSt3minIjERKT_S2_S2_
00000000 b _ZSt8__ioinit

-------------------------------------------------------

> > /opt/gcc/4.2.0-20060615/bin/g++ -c test1b.cpp test2b.cpp -I/../boost
> > nm test1b.o > test1b.txt
> > nm test2b.o > test2b.txt
> > diff test1b.txt test2b.txt

(FILES ARE IDENTICAL)

> > nm test1b.o

         U __cxa_atexit
         U __dso_handle
0000014c t
_GLOBAL__I__ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
         U __gxx_personality_v0
00000168 t __tcf_0
0000010c t _Z41__static_initialization_and_destruction_0ii
00000000 D _ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
         U _ZNKSs4sizeEv
         U _ZNKSsixEj
         U _ZNSt8ios_base4InitC1Ev
         U _ZNSt8ios_base4InitD1Ev
00000000 t _ZSt17__verify_groupingPKcjRKSs
00000000 W _ZSt3minIjERKT_S2_S2_
00000000 b _ZSt8__ioinit
Comment 1 Andrew Pinski 2006-06-16 19:01:03 UTC
No, this is different problem than you think it is.  The problem is we are emitting a constant that does not make sense at all.

*** This bug has been marked as a duplicate of 28016 ***