Re: fix for PR 4447: is this really correct?

[Kriang Lerdsuwanakij <lerdsuwa at users dot sourceforge dot net>]

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).