This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: C++ support for decimal floating point

On Wed, Sep 23, 2009 at 6:23 PM, Janis Johnson <> 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 <> wrote:
>> > On Wed, 2009-09-23 at 10:29 +0200, Richard Guenther wrote:
>> >> On Wed, Sep 23, 2009 at 2:38 AM, Janis Johnson <> 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]