From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 328 invoked by alias); 1 Dec 2001 07:02:21 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 32557 invoked from network); 1 Dec 2001 07:00:44 -0000 Received: from unknown (HELO mozart.inet.co.th) (203.150.14.100) by hostedprojects.ges.redhat.com with SMTP; 1 Dec 2001 07:00:44 -0000 Received: from loso.users.sourceforge.net (TruPPP0B126.inet.co.th [203.151.125.126]) by mozart.inet.co.th (8.9.1a/8.9.0) with ESMTP id OAA19239; Sat, 1 Dec 2001 14:00:18 +0700 (GMT+0700) Message-Id: <4.3.2.7.0.20011201134135.00ac2d50@mozart.inet.co.th> X-Sender: (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 24 Nov 2001 20:36:00 -0000 To: Joe Buck , gcc@gcc.gnu.org From: Kriang Lerdsuwanakij Subject: Re: fix for PR 4447: is this really correct? In-Reply-To: <200111301920.LAA00093@atrus.synopsys.com> References: <200111291934.LAA07213@atrus.synopsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-SW-Source: 2001-11/txt/msg01181.txt.bz2 Hi I have checked the ABI specifications (http://www.codesourcery.com/cxx-abi/abi.html) before starting on this patch. And this bloat mangling behavior is what the ABI intended. Following is from the specification with relevant clause capitalized: An expression, e.g., "B<(J+1)/2>", is encoded with a prefix traversal of the operators involved, delimited by "X...E". The operators are encoded using their two letter mangled names. For example, "B<(J+1)/2>", if J is the third template parameter, becomes "1BI Xdv pl T1_ Li1E Li2E E E" (the blanks are present only to visualize the decomposition). Note that the expression is mangled WITHOUT CONSTANT FOLDING OR OTHER SIMPLIFICATION, and without parentheses, which are implicit in the prefix representation. Except for the parentheses, therefore, it represents the source token stream. (C++ Standard reference 14.5.5.1 p. 5.) In fact, expressions (involving any operator except type casts) are already mangled that way without my patch. I can't think of an example that causes ambiguity if constant folding is performed but it looks possible :) --Kriang At 11:20 30/11/01 -0800, Joe Buck wrote: >But I am now not sure that this fix is quite correct, though it does >improve things. > >Here's the testcase: >---------------------------------------------- >template >class T { >public: > T(int); >}; > >template >T<(B1&&B2),I1+I2-int(B1&&B2)> >func(T a, T b) { > return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2); >} > >void foo(T a, Tb) { > func(a, b); >} >---------------------------------------------- > >gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's >patch, the code compiles, but doing > >nm -p crash.o | c++filt > >on Solaris gives > > >0000000000 T foo(T, T) >0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> >func(T, T) > >rather than > >0000000000 T foo(T, T) >0000000000 T T func(T, T) > >as I would expect. It may be that the oddball expression for the return >type will not affect correctness and will just contribute to bloat instead >(for the purpose of "linkonce" directives, instantiations that are really >the same will look different). But it looks wrong. > >Comments? I may still want this for 3.0.3, because it does make some >cases that ICE'd before work correctly (in my fixed-point computation >examples the relevant functions are inline so these oddball symbols >probably won't even appear). From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kriang Lerdsuwanakij To: Joe Buck , gcc@gcc.gnu.org Subject: Re: fix for PR 4447: is this really correct? Date: Fri, 30 Nov 2001 23:02:00 -0000 Message-ID: <4.3.2.7.0.20011201134135.00ac2d50@mozart.inet.co.th> References: <200111291934.LAA07213@atrus.synopsys.com> <200111301920.LAA00093@atrus.synopsys.com> X-SW-Source: 2001-11/msg01682.html Message-ID: <20011130230200.gJKXl0LAXONSKNZI-CQq9K3kO89F6_hkMHaXEYlqMII@z> Hi I have checked the ABI specifications ( http://www.codesourcery.com/cxx-abi/abi.html ) before starting on this patch. And this bloat mangling behavior is what the ABI intended. Following is from the specification with relevant clause capitalized: An expression, e.g., "B<(J+1)/2>", is encoded with a prefix traversal of the operators involved, delimited by "X...E". The operators are encoded using their two letter mangled names. For example, "B<(J+1)/2>", if J is the third template parameter, becomes "1BI Xdv pl T1_ Li1E Li2E E E" (the blanks are present only to visualize the decomposition). Note that the expression is mangled WITHOUT CONSTANT FOLDING OR OTHER SIMPLIFICATION, and without parentheses, which are implicit in the prefix representation. Except for the parentheses, therefore, it represents the source token stream. (C++ Standard reference 14.5.5.1 p. 5.) In fact, expressions (involving any operator except type casts) are already mangled that way without my patch. I can't think of an example that causes ambiguity if constant folding is performed but it looks possible :) --Kriang At 11:20 30/11/01 -0800, Joe Buck wrote: >But I am now not sure that this fix is quite correct, though it does >improve things. > >Here's the testcase: >---------------------------------------------- >template >class T { >public: > T(int); >}; > >template >T<(B1&&B2),I1+I2-int(B1&&B2)> >func(T a, T b) { > return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2); >} > >void foo(T a, Tb) { > func(a, b); >} >---------------------------------------------- > >gcc 3.0 through 3.0.2 get an ICE in the name mangler. With Kriang's >patch, the code compiles, but doing > >nm -p crash.o | c++filt > >on Solaris gives > > >0000000000 T foo(T, T) >0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> >func(T, T) > >rather than > >0000000000 T foo(T, T) >0000000000 T T func(T, T) > >as I would expect. It may be that the oddball expression for the return >type will not affect correctness and will just contribute to bloat instead >(for the purpose of "linkonce" directives, instantiations that are really >the same will look different). But it looks wrong. > >Comments? I may still want this for 3.0.3, because it does make some >cases that ICE'd before work correctly (in my fixed-point computation >examples the relevant functions are inline so these oddball symbols >probably won't even appear).