From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29947 invoked by alias); 16 Dec 2002 19:48:13 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 29928 invoked by uid 61); 16 Dec 2002 19:48:13 -0000 Date: Mon, 16 Dec 2002 11:48:00 -0000 Message-ID: <20021216194813.29927.qmail@sources.redhat.com> To: catherin@ca.ibm.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org From: bangerth@dealii.org Reply-To: bangerth@dealii.org, catherin@ca.ibm.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: c++/8963: [3.2/3.3 regression] [ABI] The same template instance is mangled with 2 different names X-SW-Source: 2002-12/txt/msg00856.txt.bz2 List-Id: 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 struct thing; template 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*) 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 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