public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net>
To: Joe Buck <jbuck@synopsys.com>, gcc@gcc.gnu.org
Subject: Re: fix for PR 4447: is this really correct?
Date: Sat, 24 Nov 2001 20:36:00 -0000	[thread overview]
Message-ID: <4.3.2.7.0.20011201134135.00ac2d50@mozart.inet.co.th> (raw)
In-Reply-To: <200111301920.LAA00093@atrus.synopsys.com>

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<bool B,int I>
>class T {
>public:
>     T(int);
>};
>
>template<bool B1,bool B2,int I1,int I2>
>T<(B1&&B2),I1+I2-int(B1&&B2)>
>func(T<B1,I1> a, T<B2,I2> b) {
>     return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
>}
>
>void foo(T<true,3> a, T<true,4>b) {
>     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<true, 3>, T<true, 4>)
>0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> 
>func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>rather than
>
>0000000000 T foo(T<true, 3>, T<true, 4>)
>0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>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).

WARNING: multiple messages have this Message-ID
From: Kriang Lerdsuwanakij <lerdsuwa@users.sourceforge.net>
To: Joe Buck <jbuck@synopsys.com>, gcc@gcc.gnu.org
Subject: Re: fix for PR 4447: is this really correct?
Date: Fri, 30 Nov 2001 23:02:00 -0000	[thread overview]
Message-ID: <4.3.2.7.0.20011201134135.00ac2d50@mozart.inet.co.th> (raw)
Message-ID: <20011130230200.gJKXl0LAXONSKNZI-CQq9K3kO89F6_hkMHaXEYlqMII@z> (raw)
In-Reply-To: <200111301920.LAA00093@atrus.synopsys.com>

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<bool B,int I>
>class T {
>public:
>     T(int);
>};
>
>template<bool B1,bool B2,int I1,int I2>
>T<(B1&&B2),I1+I2-int(B1&&B2)>
>func(T<B1,I1> a, T<B2,I2> b) {
>     return T<(B1&&B2),I1+I2-int(B1&&B2)> (I1+I2);
>}
>
>void foo(T<true,3> a, T<true,4>b) {
>     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<true, 3>, T<true, 4>)
>0000000000 T T<(true)&&(true), ((3)+(4))-(operator int((true)&&(true)))> 
>func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>rather than
>
>0000000000 T foo(T<true, 3>, T<true, 4>)
>0000000000 T T<true, 6> func<true, true, 3, 4>(T<true, 3>, T<true, 4>)
>
>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).

  reply	other threads:[~2001-12-01  7:02 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-21 18:24 GCC 3.0.3 Mark Mitchell
2001-11-21 22:25 ` Joe Buck
2001-11-21 23:26   ` Mark Mitchell
2001-11-22  0:04     ` Joe Buck
2001-11-22  0:14       ` Mark Mitchell
2001-11-22  2:58         ` Joe Buck
2001-11-22  7:35           ` Mark Mitchell
2001-11-29 17:16             ` Mark Mitchell
2001-11-29 16:15           ` Joe Buck
2001-11-29 14:25         ` Mark Mitchell
2001-11-29 13:51       ` Joe Buck
2001-11-29 12:28     ` Mark Mitchell
2001-11-23 14:47   ` fix for PR 4447: is this really correct? Joe Buck
2001-11-24 20:36     ` Kriang Lerdsuwanakij [this message]
2001-11-30 23:02       ` Kriang Lerdsuwanakij
2001-12-01 16:08       ` Joe Buck
2001-12-02  3:12         ` Kriang Lerdsuwanakij
2001-12-03  9:42           ` Mark Mitchell
2001-12-01 17:32       ` Alexandre Oliva
2001-11-30 11:20     ` Joe Buck
2001-11-29 11:51   ` GCC 3.0.3 Joe Buck
2001-11-23 14:48 ` Stephane Carrez
2001-11-23 15:52   ` Jakub Jelinek
2001-11-30 11:47     ` Jakub Jelinek
2001-11-30 11:27   ` Stephane Carrez
2001-12-03  8:34   ` Mark Mitchell
2001-11-24 21:15 ` Toon Moene
2001-11-30 23:39   ` Toon Moene
2001-11-29 10:24 ` Mark Mitchell
2001-11-23 22:03 fix for PR 4447: is this really correct? mike stump
2001-11-24  5:14 ` Joe Buck
2001-11-30 16:20   ` Joe Buck
2001-11-30 15:23 ` mike stump
2001-12-03  9:49 ` Mark Mitchell
2001-12-03  9:53   ` Joe Buck
2001-12-03  9:56     ` Mark Mitchell
2001-11-24 15:40 mike stump
2001-11-30 18:14 ` mike stump
2001-12-01 16:14 ` Joe Buck
2001-12-03 15:40 mike stump

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4.3.2.7.0.20011201134135.00ac2d50@mozart.inet.co.th \
    --to=lerdsuwa@users.sourceforge.net \
    --cc=gcc@gcc.gnu.org \
    --cc=jbuck@synopsys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).