Fw: [cxx-abi-dev] Decimal Floating Point mangling was(Fw: [cxx-abi-dev] C++0x: Mangling of rvalue reference type)s

[Michael Wong]

All, thanks I think we are getting somewhere but there seems to be still
some dangling issues.

First, an appeal that we send only to the cxx-abi group unless someone is
not on it. This avoids duplication and the fact that some mail server is
sending out messages at different times. Based on pattern of discussion so
far, I think that is Prem Rao. If Prem is on the group, then we can remove
his name.

The other way is that I would like to get Mark Mitchell in on this and
discuss this in real time. When I proposed this back in summer of last year
privately to Mark, I was constrained by confidentiality agreement from
discussing much of the details. At that time, Mark asked that I submit the
patch and with a rationale explaining why we are constraining the choices.
Now almost a year later, I can't remember if these were his exact
instructions. I suppose I could just copy Mark and ask him but let me
propose something else.

This discussion has brought up some more  issues and resolution seems
important to the outcome of what kind of mangling we should ultimately
support in the ABI, including whether we need a native mangling or not.

So I would suggest that I try to contact Mark and get a telecon together of
the interested parties with Mark arbitrating the discussion. Would people
be amenable to participate in that? Thanks.

Michael Wong
XL C++ Compiler kernel Development
IBM Canada Ltd., C2/KD2/8200/MKM
8200 Warden Avenue
Markham, Ontario  L6G 1C7
W:905-413-3283 F:905-413-4839
Boost test results
http://www-1.ibm.com/support/docview.wss?rs=2239&context=SSJT9L&uid=swg27006911

C/C++ Compilers Support Page
http://www.ibm.com/software/awdtools/ccompilers/support/
C/C++ Feature Request Interface
http://www.ibm.com/support/docview.wss?uid=swg27005811
XL Fortran Compiler Support Page
http://www.ibm.com/software/awdtools/fortran/xlfortran/support/
XL Fortran Feature Request Interface
http://www.ibm.com/support/docview.wss?uid=swg27005812

Dennis Handly <dhandly at cup.hp.com> wrote on 08/21/2007 12:09:08 AM:

> >From: Michael Wong <michaelw at ca.ibm.com>
> >I believe one of the point of an ABI is to settle on one type where
there
> >are ambiguity or possible differences in choices. Otherwise, it is not
an
> >ABI and there would be no interoperability.
>
> Exactly.

That too is what I am trying to achieve. But I want to hear out some of the
other folks who are supporting multiple choices.
>
> >So I agree with Dennis that having both types would be confusing.
> Michael Wong
>
> Unless you allow a platform to pick one.

I would like to leave that choice to the platform as much as possible
within the constrains of the ABI. I assume this statement means you let the
platform pick one to support? Or does it mean you allow the platform to
pick one based on internal implementation?
>
> >From: Sean Perry <perry at ca.ibm.com>
> >Are you trying to say that the C++ class type shall be binary compatible
> >with the C native type?  That is going to fail immediately on parameter
> >passing and return values.
>
> Why?  We just wave our ABI wands and say it can't.
>
> >then someone can throw a C
> >native type and catch it as the C++ class type.  Similar odd behaviour
> >would happen with dynamic casting.  The fact is that we have two
different
> >types because C++ choose to implement decimal floating point as a class.
> >We need two different mangling schemes.
> Sean Perry
>
> Can't we make sure we mangle them the same and so the type_info would
> be the same?
>
> >From: Michael Wong <michaelw at ca.ibm.com>
> >Absolutely not. That would be silly even to me.
>
> As Prem asks below, are you saying:
>   Are you trying to say that the C++ class type shall be binary
compatible
>   with the C native type?
>
> We want it to be the same.
>
> >The point is that for platforms that support native types, the native
type
> >mangling is available for a potentially more efficient implementation.
For
> >platforms that can only support emulation, the class library type and
its
> >mangling is available. Have I missed the point?
> Michael Wong
>
> The only point you missed is it not only to do with platforms but the
> compiler too.
Thats fine.
>
> >From: Daveed Vandevoorde <daveed at edg.com>
> >Most likely, indeed (though magical class types could be possible).
>
> Sign me up for magic.  ;-)
>
> >I still don't see why.  C signatures need no mangling.  In C++ it's a
> >class type, so there is an encoding for that.
>    Daveed
>
> Except my suggestion is that we special case that class type and mangle
> it as the native type.
That is one way if the platform can accept the native type.
>
> >From: PremAnand M Rao <premanand.rao at hp.com>
> >I am not sure what you said "Absolutely not" to.
>
> Right.
>
> >If the mangling for the type are different based on how they are
> >implemented, it removes a lot of flexibility from this choice.
> PremAnand.
>
> Right.
Also from Prem:
 > The point is that for platforms that support native types, the
 > native type mangling is available for a potentially more efficient
 > implementation. For platforms that can only support emulation,
 > the class library type and its mangling is available. Have I missed
 > the point?

>I may have misunderstood what you are saying, if so, please correct me.
>The current C++ TR specification permits an implementation to choose to
>implement the Decimal FP types as either a native type or a class type,

Yes, that is my understanding too.


>if it preserves the semantics of a class type.   If the mangling for the
>type are different based on how they are implemented, it removes a lot
>of flexibility from this choice.

So even if the platform/compiler were to choose to implement the class
magically as a native type, perhaps by embedding inside the class a private
member __decimal32 because it has it, then it would still be constrained to
mangle it as a class type as long as it maintains the class interface.
This would keep it consistent with the platform/compiler that implements it
as an emulation (perhaps with a char /bitfield member). So far, you are
still free to make that choice of internal implementation.

>From the ABI point of view, it is saying that if you implement a native
type (not one inside a class type)because you can, then the native type
must have a specific mangling to be consistent with the native type other
C++ compilers create if they also run on platforms that support native
types.

Again, if I am wrong or missed something which is a possibility I am always
willing to entertain, then let us hash it out in the teleconference because
I am finding the discussion fracturing to more confusion then actually
leading to an end.

PremAnand.

Michael Wong wrote:
> Absolutely not. That would be silly even to me.
> I want to settle the mangling chosen for the native type for platforms
that
> can support it. I am not saying there should not coexists different
> manglings for class types and native types.
> What Mark wanted, I believe was a rationale to explain why there  exists
> both types and their mangling and that is what I am seeing a convergence
> here in this discussion, for which I am glad.
> The point is that for platforms that support native types, the native
type
> mangling is available for a potentially more efficient implementation.
For
> platforms that can only support emulation, the class library type and its
> mangling is available. Have I missed the point?
>
> What I was hoping to ask was if people are sufficiently happy with this
> state so that I can write up the mangling addendum proposal?