This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
C++ support for decimal floating point
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: gcc at gcc dot gnu dot org
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Tue, 22 Sep 2009 17:38:33 -0700
- Subject: C++ support for decimal floating point
- Reply-to: janis187 at us dot ibm dot com
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