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

Reply via email to