C++ support for decimal floating point

C++ support for decimal floating point

[Janis Johnson]

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

Re: C++ support for decimal floating point

[Richard Guenther]

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?

Richard.

Re: C++ support for decimal floating point

[Janis Johnson]

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".

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.

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

Re: C++ support for decimal floating point

[Richard Henderson]

On 09/23/2009 02:11 PM, Janis Johnson wrote:
> 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.

You could special-case this in the C++ conversion to generic
by having the std::decimal classes decompose to scalars immediately.

Re: C++ support for decimal floating point

[Janis Johnson]

On Wed, 2009-09-23 at 14:21 -0700, Richard Henderson wrote:
> On 09/23/2009 02:11 PM, Janis Johnson wrote:
> > 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.
> 
> You could special-case this in the C++ conversion to generic
> by having the std::decimal classes decompose to scalars immediately.

I've been trying to find a place in the C++ front end where I can
replace all references to the class type to the scalar types, but
haven't yet found it.  Any suggestions?

Janis

Re: C++ support for decimal floating point

[Richard Henderson]

On 09/29/2009 01:20 PM, Janis Johnson wrote:
> I've been trying to find a place in the C++ front end where I can
> replace all references to the class type to the scalar types, but
> haven't yet found it.  Any suggestions?

cp_genericize?

Though I'm not sure what to do about global variables...


r~

Re: C++ support for decimal floating point

[Janis Johnson]

On Tue, 2009-09-29 at 13:37 -0700, Richard Henderson wrote:
> On 09/29/2009 01:20 PM, Janis Johnson wrote:
> > I've been trying to find a place in the C++ front end where I can
> > replace all references to the class type to the scalar types, but
> > haven't yet found it.  Any suggestions?
> 
> cp_genericize?
> 
> Though I'm not sure what to do about global variables...

That's where I've been trying, but it doesn't touch all references
to types.  Is there a way to march through all of the nodes in a
tree looking for types?

Janis

Re: C++ support for decimal floating point

[Richard Henderson]

On 09/29/2009 01:49 PM, Janis Johnson wrote:
> On Tue, 2009-09-29 at 13:37 -0700, Richard Henderson wrote:
>> On 09/29/2009 01:20 PM, Janis Johnson wrote:
>>> I've been trying to find a place in the C++ front end where I can
>>> replace all references to the class type to the scalar types, but
>>> haven't yet found it.  Any suggestions?
>>
>> cp_genericize?
>>
>> Though I'm not sure what to do about global variables...
>
> That's where I've been trying, but it doesn't touch all references
> to types.  Is there a way to march through all of the nodes in a
> tree looking for types?

cp_walk_tree, but... that is called during cp_genericize.


r~

Re: C++ support for decimal floating point

[Gabriel Dos Reis]

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.

>
> 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.

>
> 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
>
>
>
>

Re: C++ support for decimal floating point

[Janis Johnson]

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
> >

Re: C++ support for decimal floating point

[Gabriel Dos Reis]

On Wed, Sep 23, 2009 at 6:23 PM, Janis Johnson <janis187@us.ibm.com> wrote:
> 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.

I've been careful not to define a copy constructor or a destructor
for the specializations of std::complex<T> so that they get treated as PODs,
with the hope that the compiler will do the right thing.  At least on
my x86-64 box
 running openSUSE, I don't see a difference.  I've also left the
copy-n-assignment operator at the discretion of the compiler

      // The compiler knows how to do this efficiently
      // complex& operator=(const complex&);

So, if there is any difference on powerpc-*-linux, then that should be blamed on
poor ABI choice than anything else intrinsic to std::complex (or C++).
Where possible, we should look into how to fix that.

In many ways, it is assumed that std::complex<T> is isomorphic to the
GNU extension.

-- Gaby

Re: C++ support for decimal floating point

[Janis Johnson]

On Wed, 2009-09-23 at 18:39 -0500, Gabriel Dos Reis wrote:
> On Wed, Sep 23, 2009 at 6:23 PM, Janis Johnson <janis187@us.ibm.com> wrote:
> > 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.
> 
> I've been careful not to define a copy constructor or a destructor
> for the specializations of std::complex<T> so that they get treated as PODs,
> with the hope that the compiler will do the right thing.  At least on
> my x86-64 box
>  running openSUSE, I don't see a difference.  I've also left the
> copy-n-assignment operator at the discretion of the compiler
> 
>       // The compiler knows how to do this efficiently
>       // complex& operator=(const complex&);
> 
> So, if there is any difference on powerpc-*-linux, then that should be blamed on
> poor ABI choice than anything else intrinsic to std::complex (or C++).
> Where possible, we should look into how to fix that.
> 
> In many ways, it is assumed that std::complex<T> is isomorphic to the
> GNU extension.

The PowerPC 32-bit ELF ABI says that a struct is passed as a pointer
to an object or a copy of the object.  Classes are treated the same
as classes.  Does the C++ ABI have rules about classes like
std::complex that would cause them to be treated differently?

Janis

Re: C++ support for decimal floating point

[Jason Merrill]

On 09/29/2009 04:23 PM, Janis Johnson wrote:
> The PowerPC 32-bit ELF ABI says that a struct is passed as a pointer
> to an object or a copy of the object.  Classes are treated the same
> as classes.  Does the C++ ABI have rules about classes like
> std::complex that would cause them to be treated differently?

No.  Classes that are trivially copyable (such as complex) are passed 
according to the C ABI, which is suboptimal for many popular architectures.

Jason

Re: C++ support for decimal floating point

[Jason Merrill]

On 09/29/2009 04:23 PM, Janis Johnson wrote:
> The PowerPC 32-bit ELF ABI says that a struct is passed as a pointer
> to an object or a copy of the object.  Classes are treated the same
> as classes.  Does the C++ ABI have rules about classes like
> std::complex that would cause them to be treated differently?

No.  Classes that are trivially copyable (such as complex) are passed 
according to the C ABI, which is suboptimal for many popular architectures.

Jason