* C++ support for decimal floating point @ 2009-09-23 0:38 Janis Johnson 2009-09-23 8:29 ` Richard Guenther 0 siblings, 1 reply; 14+ messages in thread From: Janis Johnson @ 2009-09-23 0:38 UTC (permalink / raw) To: gcc; +Cc: libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 0:38 C++ support for decimal floating point Janis Johnson @ 2009-09-23 8:29 ` Richard Guenther 2009-09-23 21:12 ` Janis Johnson 0 siblings, 1 reply; 14+ messages in thread From: Richard Guenther @ 2009-09-23 8:29 UTC (permalink / raw) To: janis187; +Cc: gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 8:29 ` Richard Guenther @ 2009-09-23 21:12 ` Janis Johnson 2009-09-23 21:21 ` Richard Henderson 2009-09-23 21:27 ` Gabriel Dos Reis 0 siblings, 2 replies; 14+ messages in thread From: Janis Johnson @ 2009-09-23 21:12 UTC (permalink / raw) To: Richard Guenther; +Cc: gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 21:12 ` Janis Johnson @ 2009-09-23 21:21 ` Richard Henderson 2009-09-29 20:23 ` Janis Johnson 2009-09-23 21:27 ` Gabriel Dos Reis 1 sibling, 1 reply; 14+ messages in thread From: Richard Henderson @ 2009-09-23 21:21 UTC (permalink / raw) To: janis187; +Cc: Richard Guenther, gcc, libstdc++ 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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 21:21 ` Richard Henderson @ 2009-09-29 20:23 ` Janis Johnson 2009-09-29 20:50 ` Richard Henderson 0 siblings, 1 reply; 14+ messages in thread From: Janis Johnson @ 2009-09-29 20:23 UTC (permalink / raw) To: Richard Henderson; +Cc: Richard Guenther, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-29 20:23 ` Janis Johnson @ 2009-09-29 20:50 ` Richard Henderson 2009-09-29 20:51 ` Janis Johnson 0 siblings, 1 reply; 14+ messages in thread From: Richard Henderson @ 2009-09-29 20:50 UTC (permalink / raw) To: janis187; +Cc: Richard Guenther, gcc, libstdc++ 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~ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-29 20:50 ` Richard Henderson @ 2009-09-29 20:51 ` Janis Johnson 2009-09-29 21:19 ` Richard Henderson 0 siblings, 1 reply; 14+ messages in thread From: Janis Johnson @ 2009-09-29 20:51 UTC (permalink / raw) To: Richard Henderson; +Cc: Richard Guenther, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-29 20:51 ` Janis Johnson @ 2009-09-29 21:19 ` Richard Henderson 0 siblings, 0 replies; 14+ messages in thread From: Richard Henderson @ 2009-09-29 21:19 UTC (permalink / raw) To: janis187; +Cc: Richard Guenther, gcc, libstdc++ 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~ ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 21:12 ` Janis Johnson 2009-09-23 21:21 ` Richard Henderson @ 2009-09-23 21:27 ` Gabriel Dos Reis 2009-09-23 23:23 ` Janis Johnson 1 sibling, 1 reply; 14+ messages in thread From: Gabriel Dos Reis @ 2009-09-23 21:27 UTC (permalink / raw) To: janis187; +Cc: Richard Guenther, gcc, libstdc++ 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 > > > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 21:27 ` Gabriel Dos Reis @ 2009-09-23 23:23 ` Janis Johnson 2009-09-23 23:40 ` Gabriel Dos Reis 0 siblings, 1 reply; 14+ messages in thread From: Janis Johnson @ 2009-09-23 23:23 UTC (permalink / raw) To: gdr; +Cc: Richard Guenther, gcc, libstdc++ 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 > > ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 23:23 ` Janis Johnson @ 2009-09-23 23:40 ` Gabriel Dos Reis 2009-09-29 20:37 ` Janis Johnson 0 siblings, 1 reply; 14+ messages in thread From: Gabriel Dos Reis @ 2009-09-23 23:40 UTC (permalink / raw) To: janis187; +Cc: Richard Guenther, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-23 23:40 ` Gabriel Dos Reis @ 2009-09-29 20:37 ` Janis Johnson 2009-09-30 4:47 ` Jason Merrill 0 siblings, 1 reply; 14+ messages in thread From: Janis Johnson @ 2009-09-29 20:37 UTC (permalink / raw) To: Gabriel Dos Reis; +Cc: Richard Guenther, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-29 20:37 ` Janis Johnson @ 2009-09-30 4:47 ` Jason Merrill 2009-09-30 7:17 ` Jason Merrill 0 siblings, 1 reply; 14+ messages in thread From: Jason Merrill @ 2009-09-30 4:47 UTC (permalink / raw) To: janis187; +Cc: Gabriel Dos Reis, Richard Guenther, gcc, libstdc++ 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: C++ support for decimal floating point 2009-09-30 4:47 ` Jason Merrill @ 2009-09-30 7:17 ` Jason Merrill 0 siblings, 0 replies; 14+ messages in thread From: Jason Merrill @ 2009-09-30 7:17 UTC (permalink / raw) To: gcc; +Cc: libstdc++, gcc 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 ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-09-30 4:45 UTC | newest] Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-09-23 0:38 C++ support for decimal floating point Janis Johnson 2009-09-23 8:29 ` Richard Guenther 2009-09-23 21:12 ` Janis Johnson 2009-09-23 21:21 ` Richard Henderson 2009-09-29 20:23 ` Janis Johnson 2009-09-29 20:50 ` Richard Henderson 2009-09-29 20:51 ` Janis Johnson 2009-09-29 21:19 ` Richard Henderson 2009-09-23 21:27 ` Gabriel Dos Reis 2009-09-23 23:23 ` Janis Johnson 2009-09-23 23:40 ` Gabriel Dos Reis 2009-09-29 20:37 ` Janis Johnson 2009-09-30 4:47 ` Jason Merrill 2009-09-30 7:17 ` Jason Merrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).