On Wed, 2009-09-23 at 16:27 -0500, Gabriel Dos Reis wrote: > On Wed, Sep 23, 2009 at 4:11 PM, Janis Johnson <janis...@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 <janis...@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 > >
