C++ support for decimal floating point

Janis Johnson janis187@us.ibm.com
Wed Sep 23 23:23:00 GMT 2009


On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote:
> On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson <janis187@us.ibm.com> wrote:
> > On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
> >> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson <janis187@us.ibm.com> wrote:
> >> > 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.
> >>
> >> How do we (do we?) handle std::complex<> there?  My first shot would
> >> be to make sure the aggregate type has the proper mode, but I guess
> >> most target ABIs would already pass them in registers, no?
> >
> > std::complex<> is not interoperable with GCC's complex extension, which
> > is generally viewed as "unfortunate".
> 
> Could you expand on why std::complex<> is not interoperable with GCC's
> complex extension.  The reason is that I would like to know better where
> the incompatibilities come from -- I've tried to remove any.

I was just repeating what I had heard from C++ experts.  On
powerpc-linux they are currently passed and mangled differently.

> > The class types for std::decimal::decimal32 and friends do have the
> > proper modes.  I suppose I could special-case aggregates of those modes
> > but the plan was to pass these particular classes (and typedefs of
> > them) the same as scalars, rather than _any_ class with those modes.
> > I'll bring this up again on the C++ ABI mailing list.
> 
> I introduced the notion of 'literal types' in C++0x precisely so that
> compilers can pretend that user-defined types are like builtin types
> and provide appropriate support.  decimal types are literal types.  So
> are std::complex<T> for T = builtin arithmetic types.

I'm looking at these now.

> > Perhaps most target ABIs pass single-member aggregates using the
> > mode of the aggregate, but not all.  In particular, not the 32-bit
> > ELF ABI for Power.
> >
> > Janis
> >



More information about the Libstdc++ mailing list