* 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: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 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-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: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-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).