This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c++/8963: [3.2/3.3 regression] [ABI] The same template instance is mangled with 2 different names
- From: bangerth at dealii dot org
- To: catherin at ca dot ibm dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org
- Date: 16 Dec 2002 19:48:13 -0000
- Subject: Re: c++/8963: [3.2/3.3 regression] [ABI] The same template instance is mangled with 2 different names
- Reply-to: bangerth at dealii dot org, catherin at ca dot ibm dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
Old Synopsis: The same template instance is mangled with 2 different names
New Synopsis: [3.2/3.3 regression] [ABI] The same template instance is mangled with 2 different names
State-Changed-From-To: open->analyzed
State-Changed-By: bangerth
State-Changed-When: Mon Dec 16 11:48:12 2002
State-Changed-Why:
Confirmed. In essence, this happens: we have
----------------------------
template <int> struct thing;
template <int J, int K>
void stuff (thing<(unsigned char)(30)> *);
int main() {
stuff<7,8> (0);
}
--------------------------
Compile and run nm on it:
tmp/g> /home/bangerth/bin/gcc-3.3-pre/bin/c++ -c x.cc
tmp/g> nm x.o | /home/bangerth/bin/gcc-3.2/bin/c++filt
U void stuff<(int)7, (int)8>(thing<operator unsigned char((int)30)>*)
Note that the conversion operator (unsigned char)(30)
is coded into the mangled name, which I believe it
should not be since the type of the template argument
is fixed (it is integer).
This does not happen if we make the function a non-template:
------------------
template <int> struct thing;
void stuff (thing<(unsigned char)(30)> *);
int main() {
stuff (0);
}
--------------tmp/g> /home/bangerth/bin/gcc-3.3-pre/bin/c++ -c x.cc
tmp/g> nm x.o | /home/bangerth/bin/gcc-3.2/bin/c++filt
U stuff(thing<(int)30>*)
I don't have enough knowledge of the ABI standard to say
what is right and what is wrong, but I would think this
is a bug. Also, -fabi-version does not change anything.
gcc 2.95 can't compile the code at all, generating invalid
assembler logic. However, similar cases compile without
mangling the conversion operator, so I would rate this as
a regression, if it is considered a bug, which is why I
increase the priority. This way, someone with enough
knowledge will look at it eventually ;-)
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8963