[cxx-abi-dev] decimal floating point support for C++

[Dennis Handly]

>From: Janis Johnson <janis187 at us.ibm.com>
>The C support adds 3 new scalar types:  _Decimal32, _Decimal64, and
>_Decimal128.  With minor changes to GCC, including support for mangling
>those types

We have such support in aC++ for C mode.

>The C++ standards committee defined quite different support for C++ in
>ISO/IEC DTR 24733, "Extension for the programming language C++ to
>support decimal floating-point arithmetic".  It defines the support in
>terms of classes decimal32, decimal64, and decimal128 in namespace
>decimal, defined in <decimal>, and allows decimal floating-point
>literals as a conforming extension.
Janis Johnson

I was once in the process of responding to this to have some hand waving
rule that said if there was an application that had a difference between
a class implementation and a builtin implementation, this was implementation
defined.

With the only exception of providing that the builtin type always
initialized to zero.
And stating that the user couldn't take the address of any operator
conversion functions.

>From: Jason Merrill <jason at redhat.com>
>do we want to standardise the necessary compiler support?

At least special case these as not really a class.

Also _Decimal32 if a class, must be right justified in the register,
like a builtin type, not like a class.
(I mentioned that latter here before.

>From: Janis Johnson <janis187 at us.ibm.com>
>a way to use that type for extern "C" function declarations
>(or perhaps a source-level attribute) to pass the class as a scalar
>using the target's ABI for decimal float types.

You can use a type hammer, a reference cast to fool things.  But that
would require an intermediate inline function and I guess you want to
bypass that?

>From: David Vandevoorde <daveed at edg.com>
>The classes should be marked as being just generally "magical" in  
>that they're transferred like native _DecimalN types no matter what  
>the calling convention.

Right.

>We'd also need to clarify that such class types mangle with the Dd/De/ 
>Df codes and not the usual class type rules.
	Daveed

Yes.

>From: Lawrence Crowl <crowl at google.com>
>The real problem is that compilers either need to recognize the name or
>the libstdc++ source needs to specially mark them.  I lean towards doing
>the former.

Sounds good.

>From: Mark Mitchell <mark at codesourcery.com>
>It's an ugly special case, but it's an ugly special case imposed
>upon us by the fact that the C++ committee insisted on making these
>classes, rather than new datatypes, thereby making it hard to
>interoperate with C.

Right.