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).
next prev parent 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).