I've been implementing ISO/IEC TR 24733, "an extension for the
programming language C++ to support decimal floating-point arithmetic",
in GCC.  It might be ready as an experimental feature for 4.5, but I
would particularly like to get in the compiler changes that are needed
for it.

Most of the support for the TR is in new header files in libstdc++ that
depend on compiler support for decimal float scalar types.  Most of that
compiler functionality was already available in G++ via mode attributes.
I've made a couple of small fixes and have a couple more to submit, and
when those are in I'll starting running dfp tests for C++ as well as C.
The suitable tests have already been moved from gcc.dg to c-c++-common.

In order to provide interoperability with C, people on the C++ ABI
mailing list suggested that a C++ compiler should recognize the new
decimal classes defined in the TR and pass arguments of those types the
same as scalar decimal float types for a particular target.  I had this
working in an ugly way using a langhook, but that broke with LTO.  I'm
looking for the right places to record that an argument or return value
should be passed as if it were a different type, but could use some
advice about that.

Changes that are needed to the compiler:

  - mangling of decimal float types as specified by the C++ ABI
    (http://gcc.gnu.org/ml/gcc-patches/2009-09/msg01079.html)

  - don't "promote" decimal32 arguments to double for C++ varargs calls
    (trivial patch not yet submitted, waiting for mangling patch so
    tests will pass)

  - pass std::decimal::decimal32/64/128 arguments and return values the
    same as scalar decimal float values; as I said, this worked before
    the LTO merge but depended on using language-specific data way too
    late in the compilation, so now I'm starting from scratch

For the library support I have all of the functionality of section 3.1
of the TR implemented, with the exception of formatted input and output.
More importantly, I have a comprehensive set of tests for that
functionality that will be useful even if the implementation changes.
There are several issues with the library support that I'll cover in
later mail; first I'm concentrating on the compiler changes.

This message is just a heads-up that I'm working on this and would
greatly appreciate some advice about the argument-passing support.

Janis


Reply via email to