Re: [cxx-abi-dev] Discuss DFP mangling was(Re: [cxx-abi-dev] C++0x: mangling of char16_t and char32_t)

[Dennis Handly <dhandly@xxxxxxxxxx>]

>From: PremAnand M Rao <premanand.rao@xxxxxx>
>but here is the "fine tuned" document that Michael was referring to.

--------------060602000603020001050105
>Towards Common Vendor DFP Mangling

>The C++ Decimal FP TR allows an implementation to implement the C++
>Decimal FP class as a builtin type, provided the user cannot tell the
>difference.

>Calling convention interoperability
>DFP classes are standard layout types, so they are memcpy-able.  
>In summary, they are memcpy-able and you can move them around registers.

>This means that if a class is a DFP, or a struct whose only member is a
>DFP type, they can all be passed in GPR and exchange data properly with
>other structs.

Unfortunately this isn't true for _Decimal32.

>C and C++ interoperability
>This is strictly not a C++ ABI issue. ...
>Since C does no mangling, it is not a mangling issue.  But we can ask
>that if we have an extern C function with DFP type, then change the ABI
>to match C

>5. C++ class library and native interoperability
>It would seem it is possible for the C++ library to talk to the native
>type as long as there are no special copy constructor/assignment
>operator/destructors.

Due do an unrelated bug in our C99 _Decimal32 implementation, it logically
follows that we are hosed.  Unless we special case the C++ version of
_Decimal32.

I.e. the ia64 C++ ABI and the C ABI say that builtin types are passed
right justified in a 64 bit register.

But structs/classes are left justified!!
And this causes problems with _Decimal32 but not _Decimal64 and _Decimal128.