Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-27 Thread Richard Biener 
On Wed, 22 Jun 2016, Michael Meissner wrote:

> On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> > And I don't understand the layout_type change either - it looks to me
> > it could just have used
> > 
> >   SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE 
> > (TREE_TYPE (type;
> > 
> > and be done with it.  To me that looks a lot safer.
> 
> I made this change in the trunk, and now I would like approval for applying
> this code which includes the above change in the GCC 6.2 branch.
> 
> Here is the change for the trunk:
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01489.html
> 
> I tested it on both a big endian power7 and a little endian power8 systems 
> with
> no regressions.  Is it ok to apply to the GCC 6.2 branch?

Ok.

Richard.

> [gcc]
> 2016-06-22  Michael Meissner  
> 
>   Back port from trunk
>   2016-06-21  Michael Meissner  
> 
>   * stor-layout.c (layout_type): Move setting complex MODE to
>   layout_type, instead of setting it ahead of time by the caller.
> 
>   Back port from trunk
>   2016-05-11  Alan Modra  
> 
>   * config/rs6000/rs6000.c (is_complex_IBM_long_double,
>   abi_v4_pass_in_fpr): New functions.
>   (rs6000_function_arg_boundary): Exclude complex IBM long double
>   from 64-bit alignment when ABI_V4.
>   (rs6000_function_arg, rs6000_function_arg_advance_1,
>   rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.
> 
>   Back port from trunk
>   2016-05-02  Michael Meissner  
> 
>   * machmode.h (mode_complex): Add support to give the complex mode
>   for a given mode.
>   (GET_MODE_COMPLEX_MODE): Likewise.
>   * stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode
>   stored by build_complex_type and gfc_build_complex_type instead of
>   trying to figure out the appropriate mode based on the size. Raise
>   an assertion error, if the type was not set.
>   * genmodes.c (struct mode_data): Add field for the complex type of
>   the given type.
>   (blank_mode): Likewise.
>   (make_complex_modes): Remember the complex mode created in the
>   base type.
>   (emit_mode_complex): Write out the mode_complex array to map a
>   type mode to the complex version.
>   (emit_insn_modes_c): Likewise.
>   * tree.c (build_complex_type): Set the complex type to use before
>   calling layout_type.
>   * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
>   support for __float128 complex datatypes.
>   (rs6000_hard_regno_mode_ok): Likewise.
>   (rs6000_setup_reg_addr_masks): Likewise.
>   (rs6000_complex_function_value): Likewise.
>   * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise.
>   __float128 and __ibm128 complex.
>   (FLOAT128_IBM_P): Likewise.
>   (ALTIVEC_ARG_MAX_RETURN): Likewise.
>   * doc/extend.texi (Additional Floating Types): Document that
>   -mfloat128 must be used to enable __float128.  Document complex
>   __float128 and __ibm128 support.
> 
> [gcc/testsuite]
> 2016-06-22  Michael Meissner  
> 
>   Back port from trunk
>   2016-05-02  Michael Meissner  
> 
>   * gcc.target/powerpc/float128-complex-1.c: New tests for complex
>   __float128.
>   * gcc.target/powerpc/float128-complex-2.c: Likewise.
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-22 Thread Michael Meissner 
On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> And I don't understand the layout_type change either - it looks to me
> it could just have used
> 
>   SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE 
> (TREE_TYPE (type;
> 
> and be done with it.  To me that looks a lot safer.

I made this change in the trunk, and now I would like approval for applying
this code which includes the above change in the GCC 6.2 branch.

Here is the change for the trunk:
https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01489.html

I tested it on both a big endian power7 and a little endian power8 systems with
no regressions.  Is it ok to apply to the GCC 6.2 branch?

[gcc]
2016-06-22  Michael Meissner  

Back port from trunk
2016-06-21  Michael Meissner  

* stor-layout.c (layout_type): Move setting complex MODE to
layout_type, instead of setting it ahead of time by the caller.

Back port from trunk
2016-05-11  Alan Modra  

* config/rs6000/rs6000.c (is_complex_IBM_long_double,
abi_v4_pass_in_fpr): New functions.
(rs6000_function_arg_boundary): Exclude complex IBM long double
from 64-bit alignment when ABI_V4.
(rs6000_function_arg, rs6000_function_arg_advance_1,
rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.

Back port from trunk
2016-05-02  Michael Meissner  

* machmode.h (mode_complex): Add support to give the complex mode
for a given mode.
(GET_MODE_COMPLEX_MODE): Likewise.
* stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode
stored by build_complex_type and gfc_build_complex_type instead of
trying to figure out the appropriate mode based on the size. Raise
an assertion error, if the type was not set.
* genmodes.c (struct mode_data): Add field for the complex type of
the given type.
(blank_mode): Likewise.
(make_complex_modes): Remember the complex mode created in the
base type.
(emit_mode_complex): Write out the mode_complex array to map a
type mode to the complex version.
(emit_insn_modes_c): Likewise.
* tree.c (build_complex_type): Set the complex type to use before
calling layout_type.
* config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
support for __float128 complex datatypes.
(rs6000_hard_regno_mode_ok): Likewise.
(rs6000_setup_reg_addr_masks): Likewise.
(rs6000_complex_function_value): Likewise.
* config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise.
__float128 and __ibm128 complex.
(FLOAT128_IBM_P): Likewise.
(ALTIVEC_ARG_MAX_RETURN): Likewise.
* doc/extend.texi (Additional Floating Types): Document that
-mfloat128 must be used to enable __float128.  Document complex
__float128 and __ibm128 support.

[gcc/testsuite]
2016-06-22  Michael Meissner  

Back port from trunk
2016-05-02  Michael Meissner  

* gcc.target/powerpc/float128-complex-1.c: New tests for complex
__float128.
* gcc.target/powerpc/float128-complex-2.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c  (revision 237619)
+++ gcc/config/rs6000/rs6000.c  (working copy)
@@ -1882,7 +1882,7 @@ rs6000_hard_regno_nregs_internal (int re
  128-bit floating point that can go in vector registers, which has VSX
  memory addressing.  */
   if (FP_REGNO_P (regno))
-reg_size = (VECTOR_MEM_VSX_P (mode)
+reg_size = (VECTOR_MEM_VSX_P (mode) || FLOAT128_VECTOR_P (mode)
? UNITS_PER_VSX_WORD
: UNITS_PER_FP_WORD);
 
@@ -1914,6 +1914,9 @@ rs6000_hard_regno_mode_ok (int regno, ma
 {
   int last_regno = regno + rs6000_hard_regno_nregs[mode][regno] - 1;
 
+  if (COMPLEX_MODE_P (mode))
+mode = GET_MODE_INNER (mode);
+
   /* PTImode can only go in GPRs.  Quad word memory operations require even/odd
  register combinations, and use PTImode where we need to deal with quad
  word memory operations.  Don't allow quad words in the argument or frame
@@ -2716,8 +2719,17 @@ rs6000_setup_reg_addr_masks (void)
 
   for (m = 0; m < NUM_MACHINE_MODES; ++m)
 {
-  machine_mode m2 = (machine_mode)m;
-  unsigned short msize = GET_MODE_SIZE (m2);
+  machine_mode m2 = (machine_mode) m;
+  bool complex_p = false;
+  size_t msize;
+
+  if (COMPLEX_MODE_P (m2))
+   {
+ complex_p = true;
+ m2 = GET_MODE_INNER (m2);
+   }
+
+  msize = GET_MODE_SIZE (m2);
 
   /*

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-21 Thread Joseph Myers 
On Tue, 21 Jun 2016, Michael Meissner wrote:

> > I'm now working on support for TS 18661-3 _FloatN / _FloatNx type names 
> > (keywords), constant suffixes and  addiitions.  That will 
> > address, for C, the need to use modes for complex float128 (bug 32187) by 
> > allowing the standard _Complex _Float128 to be used.  The issue would 
> > still apply for C++ (I'm not including any C++ support for these type 
> > names / constant suffixes in my patch), and for complex ibm128.
> 
> Great!
> 
> Of course we will need to have some solution for C++.

Since the C++-standard way of using complex numbers is std::complex, it's 
not clear to me that the C-compatible _Complex _Float128 needs to be 
particularly conveniently avilable in C++.

Rather, where the C++ standard says "The effect of instantiating the 
template complex for any type other than float, double, or long double is 
unspecified. The specializations complex, complex, and 
complex are literal types (3.9).", presumably one should aim 
to make complex<__float128> work properly if it doesn't already.  And that 
might internally use _Complex _Float128 in some way to call libm functions 
when available, much as libstdc++ currently has _GLIBCXX_USE_C99_COMPLEX.  
And then I suppose you'd want to make appropriate literal suffixes work as 
well.  That's part of rather more generally making libstdc++ work with a 
new floating-point type; 
 has an overview of 
the sorts of things involved and links to other discussions.

Standard C++ support for decimal floating-point types, TR 24733, took the 
form of classes such as std::decimal::decimal64 rather than the C-style 
_Decimal64.  I don't know what form C++ bindings to IEEE interchange and 
extended types might take, but something similar would seem natural.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-21 Thread Michael Meissner 
On Thu, Jun 16, 2016 at 10:06:48PM +, Joseph Myers wrote:
> On Wed, 15 Jun 2016, Michael Meissner wrote:
> 
> > Note, I do feel the front ends should be modified to allow __complex 
> > __float128
> > directly rather than having to use an attribute to force the complex type 
> > (and
> > to use mode(TF) on x86 or mode(KF) on PowerPC).  It would clean up both x86 
> > and
> > PowerPC.  However, those patches aren't written yet.
> 
> I'm now working on support for TS 18661-3 _FloatN / _FloatNx type names 
> (keywords), constant suffixes and  addiitions.  That will 
> address, for C, the need to use modes for complex float128 (bug 32187) by 
> allowing the standard _Complex _Float128 to be used.  The issue would 
> still apply for C++ (I'm not including any C++ support for these type 
> names / constant suffixes in my patch), and for complex ibm128.

Great!

Of course we will need to have some solution for C++.

And we will have to live with the current stuff in GCC 6.x.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-16 Thread Joseph Myers 
On Wed, 15 Jun 2016, Michael Meissner wrote:

> Note, I do feel the front ends should be modified to allow __complex 
> __float128
> directly rather than having to use an attribute to force the complex type (and
> to use mode(TF) on x86 or mode(KF) on PowerPC).  It would clean up both x86 
> and
> PowerPC.  However, those patches aren't written yet.

I'm now working on support for TS 18661-3 _FloatN / _FloatNx type names 
(keywords), constant suffixes and  addiitions.  That will 
address, for C, the need to use modes for complex float128 (bug 32187) by 
allowing the standard _Complex _Float128 to be used.  The issue would 
still apply for C++ (I'm not including any C++ support for these type 
names / constant suffixes in my patch), and for complex ibm128.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-15 Thread Michael Meissner 
On Wed, Jun 15, 2016 at 03:12:55PM +0200, Richard Biener wrote:
> On Wed, 15 Jun 2016, Michael Meissner wrote:
> > Eventually, I decided to punt having to have explicit paths for widening.  I
> > used fractional modes for IFmode (ibm long double format) and KFmode (IEEE
> > 128-bit format).  IFmode widens to KFmode which widens to TFmode.  A backend
> > hook is used to not allow IBM long double to widen to IEEE long double and 
> > vice
> > versa.  At the moment, since there is no wider type than 128-bits, it isn't 
> > an
> > issue.
> 
> Ok, using fractional float modes is a lie though as both IFmode and KFmode
> have no insignificant bits.  I checked that if you have two same-size
> FLOAT_MODEs they still get iterated over with GET_MODE_WIDER_MODE,
> in order of appearance.  So your reason to use fractional modes was
> to make the order explicit and to avoid bogus handling in for example
> the constant pool handling which would mistake say IFmode as being
> smaller than KFmode just because one is GET_MODE_WIDER_MODE of the other
> (and both have the same precision)?  Interestingly for 
> GET_MODE_2XWIDER_MODE it "skips" the duplicate-sized and chooses
> the "first" one.
> 
> I guess having to have both float formats usable at the same time
> is not really supported by our mode machinery.
> 
> > Note, I do feel the front ends should be modified to allow __complex 
> > __float128 directly rather than having to use an attribute to force the 
> > complex type (and to use mode(TF) on x86 or mode(KF) on PowerPC).  It 
> > would clean up both x86 and PowerPC.  However, those patches aren't 
> > written yet.
> 
> Sure, but that's independent of the modes issue.
> 
> Anyway, I'm fine with the backport if you sort out the issue with
> the assert in layout_type.

I did change the code as you suggested, and it did bootstrap and have no
regressions.  When I get back on Monday, I will look at implementing the fix in
trunk, and then putting the revised patch into GCC 6.2.

Thanks.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-15 Thread Richard Biener 
On Wed, 15 Jun 2016, Michael Meissner wrote:

> On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> > On Tue, 14 Jun 2016, Bill Schmidt wrote:
> > 
> > > Hi Richard,
> > > 
> > > As nobody else has replied, let me take a stab at this one.
> > > 
> > > > On Jun 10, 2016, at 2:06 AM, Richard Biener  wrote:
> > > > 
> > > > On Thu, 9 Jun 2016, Michael Meissner wrote:
> > > > 
> > > >> I'm including the global reviewers on the list.  I just want to be 
> > > >> sure that
> > > >> there is no problem installing these patches on the GCC 6.2 branch.  
> > > >> While it
> > > >> is technically an enchancement, it is needed to be able to install the 
> > > >> glibc
> > > >> support that is needed to complete the work to add IEEE 128-bit 
> > > >> floating point.
> > > >> 
> > > >> The issue being fixed is that when we are creating the complex type, 
> > > >> we used to
> > > >> do a lookup for the size, and that fails on the PowerPC which has 2 
> > > >> 128-bit
> > > >> floating point types (__ibm128 and __float128, with long double 
> > > >> currently
> > > >> defaulting to __ibm128).
> > > > 
> > > > As this enhancement includes middle-end changes I am hesitant to approve
> > > > it for the branch.  Why is it desirable to backport this change?
> > > 
> > > It comes down to community requirements and schedules.  We are in the 
> > > process of
> > > replacing the incompatible IBM long double type with true IEEE-754 
> > > 128-bit floating
> > > point (__float128).  This is a complex multi-stage process where we will 
> > > have to
> > > maintain the functionality of the existing IBM long double for backward 
> > > compatibility
> > > while the new type is implemented.  This impacts multiple packages, 
> > > starting with
> > > gcc and glibc.
> > > 
> > > The glibc maintainers have indicated that work there depends on a certain 
> > > level of
> > > functionality within GCC.  Specifically, both the old and new types must 
> > > be supported,
> > > including corresponding complex types.  Unfortunately the realization 
> > > that the complex
> > > types had to be supported came late, and this work didn't fully make it 
> > > into GCC 6.1.
> > > 
> > > (Part of the problem that has made this whole effort difficult is that it 
> > > is complicated to
> > > maintain two floating-point types of the exact same size.)
> > > 
> > > In any case, the glibc maintainers require this work in GCC 6 so that 
> > > work can begin
> > > in glibc 2.24, with completion scheduled in glibc 2.25.  We are asking 
> > > for an exception 
> > > for this patch in order to allow those schedules to move forward.
> > > 
> > > So that's the history as I understand it... Perhaps others can jump in if 
> > > I've munged
> > > or omitted anything important.
> > 
> > Ok, I see the reason for the backport then.  Looking at the patch
> > the only fragile thing is the layout_type change give it adds an assert
> > and you did need to change frontends (but not all of them?).  I'm not
> > sure about testsuite coverage for complex type for, say, Go or Ada
> > or Java.
> 
> I added the assert after the review from Berndt.  It was to make sure there
> were no other callers to layout_type to create complex nodes.
> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00077.html
> 
> > And I don't understand the layout_type change either - it looks to me
> > it could just have used
> > 
> >   SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE 
> > (TREE_TYPE (type;
> > 
> > and be done with it.  To me that looks a lot safer.
> 
> It has been some time since I looked at the code, I will have to investigate
> it futher.
> 
> Note, I will be offline for the next 4 days.
> 
> > With now having two complex FP modes with the same size how does
> > iteration over MODE_COMPLEX_FLOAT work with GET_MODE_WIDER_MODE?
> > Is the outcome random?  Or do we visit both modes?  That is, could
> > GET_MODE_COMPLEX_MODE be implemented with iterating over complex modes
> > and in addition to size also match the component mode instead?
> 
> I struggled quite a bit with GET_WIDER_MODE.  There are three distinct usage
> cases in the compiler.  One case uses GET_WIDER_MODE to initialize all of the
> types.  Here you want to visit all of the types (though we could change the
> code, since genmode does sort the types so that all of the types for a given
> class are together).
> 
> Another case is the normal case, where given a type, go up to a wider type 
> that
> might implment the code you are looking for.
> 
> A third case is when generating floating point constants in the constant pool,
> see if there is a smaller type that maintains the precision.
> 
> Eventually, I decided to punt having to have explicit paths for widening.  I
> used fractional modes for IFmode (ibm long double format) and KFmode (IEEE
> 128-bit format).  IFmode widens to KFmode which widens to TFmode.  A backend
> hook is used to not allow IBM long double to widen to IEEE long

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-15 Thread Michael Meissner 
On Wed, Jun 15, 2016 at 11:01:05AM +0200, Richard Biener wrote:
> On Tue, 14 Jun 2016, Bill Schmidt wrote:
> 
> > Hi Richard,
> > 
> > As nobody else has replied, let me take a stab at this one.
> > 
> > > On Jun 10, 2016, at 2:06 AM, Richard Biener  wrote:
> > > 
> > > On Thu, 9 Jun 2016, Michael Meissner wrote:
> > > 
> > >> I'm including the global reviewers on the list.  I just want to be sure 
> > >> that
> > >> there is no problem installing these patches on the GCC 6.2 branch.  
> > >> While it
> > >> is technically an enchancement, it is needed to be able to install the 
> > >> glibc
> > >> support that is needed to complete the work to add IEEE 128-bit floating 
> > >> point.
> > >> 
> > >> The issue being fixed is that when we are creating the complex type, we 
> > >> used to
> > >> do a lookup for the size, and that fails on the PowerPC which has 2 
> > >> 128-bit
> > >> floating point types (__ibm128 and __float128, with long double currently
> > >> defaulting to __ibm128).
> > > 
> > > As this enhancement includes middle-end changes I am hesitant to approve
> > > it for the branch.  Why is it desirable to backport this change?
> > 
> > It comes down to community requirements and schedules.  We are in the 
> > process of
> > replacing the incompatible IBM long double type with true IEEE-754 128-bit 
> > floating
> > point (__float128).  This is a complex multi-stage process where we will 
> > have to
> > maintain the functionality of the existing IBM long double for backward 
> > compatibility
> > while the new type is implemented.  This impacts multiple packages, 
> > starting with
> > gcc and glibc.
> > 
> > The glibc maintainers have indicated that work there depends on a certain 
> > level of
> > functionality within GCC.  Specifically, both the old and new types must be 
> > supported,
> > including corresponding complex types.  Unfortunately the realization that 
> > the complex
> > types had to be supported came late, and this work didn't fully make it 
> > into GCC 6.1.
> > 
> > (Part of the problem that has made this whole effort difficult is that it 
> > is complicated to
> > maintain two floating-point types of the exact same size.)
> > 
> > In any case, the glibc maintainers require this work in GCC 6 so that work 
> > can begin
> > in glibc 2.24, with completion scheduled in glibc 2.25.  We are asking for 
> > an exception 
> > for this patch in order to allow those schedules to move forward.
> > 
> > So that's the history as I understand it... Perhaps others can jump in if 
> > I've munged
> > or omitted anything important.
> 
> Ok, I see the reason for the backport then.  Looking at the patch
> the only fragile thing is the layout_type change give it adds an assert
> and you did need to change frontends (but not all of them?).  I'm not
> sure about testsuite coverage for complex type for, say, Go or Ada
> or Java.

I added the assert after the review from Berndt.  It was to make sure there
were no other callers to layout_type to create complex nodes.
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg00077.html

> And I don't understand the layout_type change either - it looks to me
> it could just have used
> 
>   SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE 
> (TREE_TYPE (type;
> 
> and be done with it.  To me that looks a lot safer.

It has been some time since I looked at the code, I will have to investigate
it futher.

Note, I will be offline for the next 4 days.

> With now having two complex FP modes with the same size how does
> iteration over MODE_COMPLEX_FLOAT work with GET_MODE_WIDER_MODE?
> Is the outcome random?  Or do we visit both modes?  That is, could
> GET_MODE_COMPLEX_MODE be implemented with iterating over complex modes
> and in addition to size also match the component mode instead?

I struggled quite a bit with GET_WIDER_MODE.  There are three distinct usage
cases in the compiler.  One case uses GET_WIDER_MODE to initialize all of the
types.  Here you want to visit all of the types (though we could change the
code, since genmode does sort the types so that all of the types for a given
class are together).

Another case is the normal case, where given a type, go up to a wider type that
might implment the code you are looking for.

A third case is when generating floating point constants in the constant pool,
see if there is a smaller type that maintains the precision.

Eventually, I decided to punt having to have explicit paths for widening.  I
used fractional modes for IFmode (ibm long double format) and KFmode (IEEE
128-bit format).  IFmode widens to KFmode which widens to TFmode.  A backend
hook is used to not allow IBM long double to widen to IEEE long double and vice
versa.  At the moment, since there is no wider type than 128-bits, it isn't an
issue.

Note, I do feel the front ends should be modified to allow __complex __float128
directly rather than having to use an attribute to force the complex type (and
to use mode(TF) on

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-15 Thread Richard Biener 
On Tue, 14 Jun 2016, Bill Schmidt wrote:

> Hi Richard,
> 
> As nobody else has replied, let me take a stab at this one.
> 
> > On Jun 10, 2016, at 2:06 AM, Richard Biener  wrote:
> > 
> > On Thu, 9 Jun 2016, Michael Meissner wrote:
> > 
> >> I'm including the global reviewers on the list.  I just want to be sure 
> >> that
> >> there is no problem installing these patches on the GCC 6.2 branch.  While 
> >> it
> >> is technically an enchancement, it is needed to be able to install the 
> >> glibc
> >> support that is needed to complete the work to add IEEE 128-bit floating 
> >> point.
> >> 
> >> The issue being fixed is that when we are creating the complex type, we 
> >> used to
> >> do a lookup for the size, and that fails on the PowerPC which has 2 128-bit
> >> floating point types (__ibm128 and __float128, with long double currently
> >> defaulting to __ibm128).
> > 
> > As this enhancement includes middle-end changes I am hesitant to approve
> > it for the branch.  Why is it desirable to backport this change?
> 
> It comes down to community requirements and schedules.  We are in the process 
> of
> replacing the incompatible IBM long double type with true IEEE-754 128-bit 
> floating
> point (__float128).  This is a complex multi-stage process where we will have 
> to
> maintain the functionality of the existing IBM long double for backward 
> compatibility
> while the new type is implemented.  This impacts multiple packages, starting 
> with
> gcc and glibc.
> 
> The glibc maintainers have indicated that work there depends on a certain 
> level of
> functionality within GCC.  Specifically, both the old and new types must be 
> supported,
> including corresponding complex types.  Unfortunately the realization that 
> the complex
> types had to be supported came late, and this work didn't fully make it into 
> GCC 6.1.
> 
> (Part of the problem that has made this whole effort difficult is that it is 
> complicated to
> maintain two floating-point types of the exact same size.)
> 
> In any case, the glibc maintainers require this work in GCC 6 so that work 
> can begin
> in glibc 2.24, with completion scheduled in glibc 2.25.  We are asking for an 
> exception 
> for this patch in order to allow those schedules to move forward.
> 
> So that's the history as I understand it... Perhaps others can jump in if 
> I've munged
> or omitted anything important.

Ok, I see the reason for the backport then.  Looking at the patch
the only fragile thing is the layout_type change give it adds an assert
and you did need to change frontends (but not all of them?).  I'm not
sure about testsuite coverage for complex type for, say, Go or Ada
or Java.

And I don't understand the layout_type change either - it looks to me
it could just have used

  SET_TYPE_MODE (type, GET_MODE_COMPLEX_MODE (TYPE_MODE 
(TREE_TYPE (type;

and be done with it.  To me that looks a lot safer.

With now having two complex FP modes with the same size how does
iteration over MODE_COMPLEX_FLOAT work with GET_MODE_WIDER_MODE?
Is the outcome random?  Or do we visit both modes?  That is, could
GET_MODE_COMPLEX_MODE be implemented with iterating over complex modes
and in addition to size also match the component mode instead?

[I realize this is just backports but at least the layout_type change
looks dangerous to me]

Thanks,
Richard.

> Thanks!
> Bill
> 
> > 
> > Thanks,
> > Richard.
> > 
> >> On Fri, Jun 03, 2016 at 09:33:35AM -0400, Michael Meissner wrote:
> >>> These patches were installed on the trunk on May 2nd, with a fix from Alan
> >>> Modra on May 11th.  Unless I here objections in the next few days, I will
> >>> commit these changes to the GCC 6.x branch.  These changes will allow 
> >>> people to
> >>> use complex __float128 types (via an attribute) on the PowerPC.
> >>> 
> >>> Note, we will need patches to libgcc to fully enable complex __float128 
> >>> support
> >>> on the PowerPC.  These patches enable the compiler support, so that the 
> >>> libgcc
> >>> changes can be coded.
> >>> 
> >>> In addition to bootstrapping and regtesting on the PowerPC (little endian
> >>> power8), I also bootstrapped and regested the changes on x86_64 running 
> >>> RHEL
> >>> 6.2.  There were no regressions in either case.
> >>> 
> >>> [gcc]
> >>> 2016-06-02  Michael Meissner  
> >>> 
> >>>   Back port from trunk
> >>>   2016-05-11  Alan Modra  
> >>> 
> >>>   * config/rs6000/rs6000.c (is_complex_IBM_long_double,
> >>>   abi_v4_pass_in_fpr): New functions.
> >>>   (rs6000_function_arg_boundary): Exclude complex IBM long double
> >>>   from 64-bit alignment when ABI_V4.
> >>>   (rs6000_function_arg, rs6000_function_arg_advance_1,
> >>>   rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.
> >>> 
> >>>   Back port from trunk
> >>>   2016-05-02  Michael Meissner  
> >>> 
> >>>   * machmode.h (mode_complex): Add support to give the complex mode
> >>>   for a

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-14 Thread Bill Schmidt 
Hi Richard,

As nobody else has replied, let me take a stab at this one.

> On Jun 10, 2016, at 2:06 AM, Richard Biener  wrote:
> 
> On Thu, 9 Jun 2016, Michael Meissner wrote:
> 
>> I'm including the global reviewers on the list.  I just want to be sure that
>> there is no problem installing these patches on the GCC 6.2 branch.  While it
>> is technically an enchancement, it is needed to be able to install the glibc
>> support that is needed to complete the work to add IEEE 128-bit floating 
>> point.
>> 
>> The issue being fixed is that when we are creating the complex type, we used 
>> to
>> do a lookup for the size, and that fails on the PowerPC which has 2 128-bit
>> floating point types (__ibm128 and __float128, with long double currently
>> defaulting to __ibm128).
> 
> As this enhancement includes middle-end changes I am hesitant to approve
> it for the branch.  Why is it desirable to backport this change?

It comes down to community requirements and schedules.  We are in the process of
replacing the incompatible IBM long double type with true IEEE-754 128-bit 
floating
point (__float128).  This is a complex multi-stage process where we will have to
maintain the functionality of the existing IBM long double for backward 
compatibility
while the new type is implemented.  This impacts multiple packages, starting 
with
gcc and glibc.

The glibc maintainers have indicated that work there depends on a certain level 
of
functionality within GCC.  Specifically, both the old and new types must be 
supported,
including corresponding complex types.  Unfortunately the realization that the 
complex
types had to be supported came late, and this work didn't fully make it into 
GCC 6.1.

(Part of the problem that has made this whole effort difficult is that it is 
complicated to
maintain two floating-point types of the exact same size.)

In any case, the glibc maintainers require this work in GCC 6 so that work can 
begin
in glibc 2.24, with completion scheduled in glibc 2.25.  We are asking for an 
exception 
for this patch in order to allow those schedules to move forward.

So that's the history as I understand it... Perhaps others can jump in if I've 
munged
or omitted anything important.

Thanks!
Bill

> 
> Thanks,
> Richard.
> 
>> On Fri, Jun 03, 2016 at 09:33:35AM -0400, Michael Meissner wrote:
>>> These patches were installed on the trunk on May 2nd, with a fix from Alan
>>> Modra on May 11th.  Unless I here objections in the next few days, I will
>>> commit these changes to the GCC 6.x branch.  These changes will allow 
>>> people to
>>> use complex __float128 types (via an attribute) on the PowerPC.
>>> 
>>> Note, we will need patches to libgcc to fully enable complex __float128 
>>> support
>>> on the PowerPC.  These patches enable the compiler support, so that the 
>>> libgcc
>>> changes can be coded.
>>> 
>>> In addition to bootstrapping and regtesting on the PowerPC (little endian
>>> power8), I also bootstrapped and regested the changes on x86_64 running RHEL
>>> 6.2.  There were no regressions in either case.
>>> 
>>> [gcc]
>>> 2016-06-02  Michael Meissner  
>>> 
>>> Back port from trunk
>>> 2016-05-11  Alan Modra  
>>> 
>>> * config/rs6000/rs6000.c (is_complex_IBM_long_double,
>>> abi_v4_pass_in_fpr): New functions.
>>> (rs6000_function_arg_boundary): Exclude complex IBM long double
>>> from 64-bit alignment when ABI_V4.
>>> (rs6000_function_arg, rs6000_function_arg_advance_1,
>>> rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.
>>> 
>>> Back port from trunk
>>> 2016-05-02  Michael Meissner  
>>> 
>>> * machmode.h (mode_complex): Add support to give the complex mode
>>> for a given mode.
>>> (GET_MODE_COMPLEX_MODE): Likewise.
>>> * stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode
>>> stored by build_complex_type and gfc_build_complex_type instead of
>>> trying to figure out the appropriate mode based on the size. Raise
>>> an assertion error, if the type was not set.
>>> * genmodes.c (struct mode_data): Add field for the complex type of
>>> the given type.
>>> (blank_mode): Likewise.
>>> (make_complex_modes): Remember the complex mode created in the
>>> base type.
>>> (emit_mode_complex): Write out the mode_complex array to map a
>>> type mode to the complex version.
>>> (emit_insn_modes_c): Likewise.
>>> * tree.c (build_complex_type): Set the complex type to use before
>>> calling layout_type.
>>> * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
>>> support for __float128 complex datatypes.
>>> (rs6000_hard_regno_mode_ok): Likewise.
>>> (rs6000_setup_reg_addr_masks): Likewise.
>>> (rs6000_complex_function_value): Likewise.
>>> * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise.
>>> __float128 and __ibm128 complex.
>>> (FLOAT128_IBM_P):

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-10 Thread Richard Biener 
On Thu, 9 Jun 2016, Michael Meissner wrote:

> I'm including the global reviewers on the list.  I just want to be sure that
> there is no problem installing these patches on the GCC 6.2 branch.  While it
> is technically an enchancement, it is needed to be able to install the glibc
> support that is needed to complete the work to add IEEE 128-bit floating 
> point.
> 
> The issue being fixed is that when we are creating the complex type, we used 
> to
> do a lookup for the size, and that fails on the PowerPC which has 2 128-bit
> floating point types (__ibm128 and __float128, with long double currently
> defaulting to __ibm128).

As this enhancement includes middle-end changes I am hesitant to approve
it for the branch.  Why is it desirable to backport this change?

Thanks,
Richard.

> On Fri, Jun 03, 2016 at 09:33:35AM -0400, Michael Meissner wrote:
> > These patches were installed on the trunk on May 2nd, with a fix from Alan
> > Modra on May 11th.  Unless I here objections in the next few days, I will
> > commit these changes to the GCC 6.x branch.  These changes will allow 
> > people to
> > use complex __float128 types (via an attribute) on the PowerPC.
> > 
> > Note, we will need patches to libgcc to fully enable complex __float128 
> > support
> > on the PowerPC.  These patches enable the compiler support, so that the 
> > libgcc
> > changes can be coded.
> > 
> > In addition to bootstrapping and regtesting on the PowerPC (little endian
> > power8), I also bootstrapped and regested the changes on x86_64 running RHEL
> > 6.2.  There were no regressions in either case.
> > 
> > [gcc]
> > 2016-06-02  Michael Meissner  
> > 
> > Back port from trunk
> > 2016-05-11  Alan Modra  
> > 
> > * config/rs6000/rs6000.c (is_complex_IBM_long_double,
> > abi_v4_pass_in_fpr): New functions.
> > (rs6000_function_arg_boundary): Exclude complex IBM long double
> > from 64-bit alignment when ABI_V4.
> > (rs6000_function_arg, rs6000_function_arg_advance_1,
> > rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.
> > 
> > Back port from trunk
> > 2016-05-02  Michael Meissner  
> > 
> > * machmode.h (mode_complex): Add support to give the complex mode
> > for a given mode.
> > (GET_MODE_COMPLEX_MODE): Likewise.
> > * stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode
> > stored by build_complex_type and gfc_build_complex_type instead of
> > trying to figure out the appropriate mode based on the size. Raise
> > an assertion error, if the type was not set.
> > * genmodes.c (struct mode_data): Add field for the complex type of
> > the given type.
> > (blank_mode): Likewise.
> > (make_complex_modes): Remember the complex mode created in the
> > base type.
> > (emit_mode_complex): Write out the mode_complex array to map a
> > type mode to the complex version.
> > (emit_insn_modes_c): Likewise.
> > * tree.c (build_complex_type): Set the complex type to use before
> > calling layout_type.
> > * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
> > support for __float128 complex datatypes.
> > (rs6000_hard_regno_mode_ok): Likewise.
> > (rs6000_setup_reg_addr_masks): Likewise.
> > (rs6000_complex_function_value): Likewise.
> > * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise.
> > __float128 and __ibm128 complex.
> > (FLOAT128_IBM_P): Likewise.
> > (ALTIVEC_ARG_MAX_RETURN): Likewise.
> > * doc/extend.texi (Additional Floating Types): Document that
> > -mfloat128 must be used to enable __float128.  Document complex
> > __float128 and __ibm128 support.
> > 
> > [gcc/fortran]
> > 2016-06-02  Michael Meissner  
> > 
> > Back port from trunk
> > 2016-05-02  Michael Meissner  
> > 
> > * trans-types.c (gfc_build_complex_type):
> > 
> > [gcc/testsuite]
> > 2016-06-02  Michael Meissner  
> > 
> > Back port from trunk
> > 2016-05-02  Michael Meissner  
> > 
> > * gcc.target/powerpc/float128-complex-1.c: New tests for complex
> > __float128.
> > * gcc.target/powerpc/float128-complex-2.c: Likewise.
> > 
> > -- 
> > Michael Meissner, IBM
> > IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
> > email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
> 
> > Index: gcc/machmode.h
> > ===
> > --- gcc/machmode.h  (revision 237045)
> > +++ gcc/machmode.h  (working copy)
> > @@ -269,6 +269,10 @@ extern const unsigned char mode_wider[NU
> >  extern const unsigned char mode_2xwider[NUM_MACHINE_MODES];
> >  #define GET_MODE_2XWIDER_MODE(MODE) ((machine_mode) mode_2xwider[MODE])
> > 
> > +/* Get the complex mode from the component mode.  */
> > +extern const unsigned char

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-09 Thread Segher Boessenkool 
On Thu, Jun 09, 2016 at 04:06:53PM -0400, Michael Meissner wrote:
> I'm including the global reviewers on the list.  I just want to be sure that
> there is no problem installing these patches on the GCC 6.2 branch.  While it
> is technically an enchancement, it is needed to be able to install the glibc
> support that is needed to complete the work to add IEEE 128-bit floating 
> point.
> 
> The issue being fixed is that when we are creating the complex type, we used 
> to
> do a lookup for the size, and that fails on the PowerPC which has 2 128-bit
> floating point types (__ibm128 and __float128, with long double currently
> defaulting to __ibm128).

The rs6000 parts are okay to backport to 6.

Thanks,


Segher

Re: [PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-09 Thread Michael Meissner 
I'm including the global reviewers on the list.  I just want to be sure that
there is no problem installing these patches on the GCC 6.2 branch.  While it
is technically an enchancement, it is needed to be able to install the glibc
support that is needed to complete the work to add IEEE 128-bit floating point.

The issue being fixed is that when we are creating the complex type, we used to
do a lookup for the size, and that fails on the PowerPC which has 2 128-bit
floating point types (__ibm128 and __float128, with long double currently
defaulting to __ibm128).

On Fri, Jun 03, 2016 at 09:33:35AM -0400, Michael Meissner wrote:
> These patches were installed on the trunk on May 2nd, with a fix from Alan
> Modra on May 11th.  Unless I here objections in the next few days, I will
> commit these changes to the GCC 6.x branch.  These changes will allow people 
> to
> use complex __float128 types (via an attribute) on the PowerPC.
> 
> Note, we will need patches to libgcc to fully enable complex __float128 
> support
> on the PowerPC.  These patches enable the compiler support, so that the libgcc
> changes can be coded.
> 
> In addition to bootstrapping and regtesting on the PowerPC (little endian
> power8), I also bootstrapped and regested the changes on x86_64 running RHEL
> 6.2.  There were no regressions in either case.
> 
> [gcc]
> 2016-06-02  Michael Meissner  
> 
>   Back port from trunk
>   2016-05-11  Alan Modra  
> 
>   * config/rs6000/rs6000.c (is_complex_IBM_long_double,
>   abi_v4_pass_in_fpr): New functions.
>   (rs6000_function_arg_boundary): Exclude complex IBM long double
>   from 64-bit alignment when ABI_V4.
>   (rs6000_function_arg, rs6000_function_arg_advance_1,
>   rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.
> 
>   Back port from trunk
>   2016-05-02  Michael Meissner  
> 
>   * machmode.h (mode_complex): Add support to give the complex mode
>   for a given mode.
>   (GET_MODE_COMPLEX_MODE): Likewise.
>   * stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode
>   stored by build_complex_type and gfc_build_complex_type instead of
>   trying to figure out the appropriate mode based on the size. Raise
>   an assertion error, if the type was not set.
>   * genmodes.c (struct mode_data): Add field for the complex type of
>   the given type.
>   (blank_mode): Likewise.
>   (make_complex_modes): Remember the complex mode created in the
>   base type.
>   (emit_mode_complex): Write out the mode_complex array to map a
>   type mode to the complex version.
>   (emit_insn_modes_c): Likewise.
>   * tree.c (build_complex_type): Set the complex type to use before
>   calling layout_type.
>   * config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
>   support for __float128 complex datatypes.
>   (rs6000_hard_regno_mode_ok): Likewise.
>   (rs6000_setup_reg_addr_masks): Likewise.
>   (rs6000_complex_function_value): Likewise.
>   * config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise.
>   __float128 and __ibm128 complex.
>   (FLOAT128_IBM_P): Likewise.
>   (ALTIVEC_ARG_MAX_RETURN): Likewise.
>   * doc/extend.texi (Additional Floating Types): Document that
>   -mfloat128 must be used to enable __float128.  Document complex
>   __float128 and __ibm128 support.
> 
> [gcc/fortran]
> 2016-06-02  Michael Meissner  
> 
>   Back port from trunk
>   2016-05-02  Michael Meissner  
> 
>   * trans-types.c (gfc_build_complex_type):
> 
> [gcc/testsuite]
> 2016-06-02  Michael Meissner  
> 
>   Back port from trunk
>   2016-05-02  Michael Meissner  
> 
>   * gcc.target/powerpc/float128-complex-1.c: New tests for complex
>   __float128.
>   * gcc.target/powerpc/float128-complex-2.c: Likewise.
> 
> -- 
> Michael Meissner, IBM
> IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
> email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

> Index: gcc/machmode.h
> ===
> --- gcc/machmode.h(revision 237045)
> +++ gcc/machmode.h(working copy)
> @@ -269,6 +269,10 @@ extern const unsigned char mode_wider[NU
>  extern const unsigned char mode_2xwider[NUM_MACHINE_MODES];
>  #define GET_MODE_2XWIDER_MODE(MODE) ((machine_mode) mode_2xwider[MODE])
> 
> +/* Get the complex mode from the component mode.  */
> +extern const unsigned char mode_complex[NUM_MACHINE_MODES];
> +#define GET_MODE_COMPLEX_MODE(MODE) ((machine_mode) mode_complex[MODE])
> +
>  /* Return the mode for data of a given size SIZE and mode class CLASS.
> If LIMIT is nonzero, then don't use modes bigger than MAX_FIXED_MODE_SIZE.
> The value is BLKmode if no other mode is found.  */
>

[PATCH] Backport PowerPC complex __float128 compiler support to GCC 6.x

2016-06-03 Thread Michael Meissner 
These patches were installed on the trunk on May 2nd, with a fix from Alan
Modra on May 11th.  Unless I here objections in the next few days, I will
commit these changes to the GCC 6.x branch.  These changes will allow people to
use complex __float128 types (via an attribute) on the PowerPC.

Note, we will need patches to libgcc to fully enable complex __float128 support
on the PowerPC.  These patches enable the compiler support, so that the libgcc
changes can be coded.

In addition to bootstrapping and regtesting on the PowerPC (little endian
power8), I also bootstrapped and regested the changes on x86_64 running RHEL
6.2.  There were no regressions in either case.

[gcc]
2016-06-02  Michael Meissner  

Back port from trunk
2016-05-11  Alan Modra  

* config/rs6000/rs6000.c (is_complex_IBM_long_double,
abi_v4_pass_in_fpr): New functions.
(rs6000_function_arg_boundary): Exclude complex IBM long double
from 64-bit alignment when ABI_V4.
(rs6000_function_arg, rs6000_function_arg_advance_1,
rs6000_gimplify_va_arg): Use abi_v4_pass_in_fpr.

Back port from trunk
2016-05-02  Michael Meissner  

* machmode.h (mode_complex): Add support to give the complex mode
for a given mode.
(GET_MODE_COMPLEX_MODE): Likewise.
* stor-layout.c (layout_type): For COMPLEX_TYPE, use the mode
stored by build_complex_type and gfc_build_complex_type instead of
trying to figure out the appropriate mode based on the size. Raise
an assertion error, if the type was not set.
* genmodes.c (struct mode_data): Add field for the complex type of
the given type.
(blank_mode): Likewise.
(make_complex_modes): Remember the complex mode created in the
base type.
(emit_mode_complex): Write out the mode_complex array to map a
type mode to the complex version.
(emit_insn_modes_c): Likewise.
* tree.c (build_complex_type): Set the complex type to use before
calling layout_type.
* config/rs6000/rs6000.c (rs6000_hard_regno_nregs_internal): Add
support for __float128 complex datatypes.
(rs6000_hard_regno_mode_ok): Likewise.
(rs6000_setup_reg_addr_masks): Likewise.
(rs6000_complex_function_value): Likewise.
* config/rs6000/rs6000.h (FLOAT128_IEEE_P): Likewise.
__float128 and __ibm128 complex.
(FLOAT128_IBM_P): Likewise.
(ALTIVEC_ARG_MAX_RETURN): Likewise.
* doc/extend.texi (Additional Floating Types): Document that
-mfloat128 must be used to enable __float128.  Document complex
__float128 and __ibm128 support.

[gcc/fortran]
2016-06-02  Michael Meissner  

Back port from trunk
2016-05-02  Michael Meissner  

* trans-types.c (gfc_build_complex_type):

[gcc/testsuite]
2016-06-02  Michael Meissner  

Back port from trunk
2016-05-02  Michael Meissner  

* gcc.target/powerpc/float128-complex-1.c: New tests for complex
__float128.
* gcc.target/powerpc/float128-complex-2.c: Likewise.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Index: gcc/machmode.h
===
--- gcc/machmode.h  (revision 237045)
+++ gcc/machmode.h  (working copy)
@@ -269,6 +269,10 @@ extern const unsigned char mode_wider[NU
 extern const unsigned char mode_2xwider[NUM_MACHINE_MODES];
 #define GET_MODE_2XWIDER_MODE(MODE) ((machine_mode) mode_2xwider[MODE])
 
+/* Get the complex mode from the component mode.  */
+extern const unsigned char mode_complex[NUM_MACHINE_MODES];
+#define GET_MODE_COMPLEX_MODE(MODE) ((machine_mode) mode_complex[MODE])
+
 /* Return the mode for data of a given size SIZE and mode class CLASS.
If LIMIT is nonzero, then don't use modes bigger than MAX_FIXED_MODE_SIZE.
The value is BLKmode if no other mode is found.  */
Index: gcc/stor-layout.c
===
--- gcc/stor-layout.c   (revision 237045)
+++ gcc/stor-layout.c   (working copy)
@@ -2146,11 +2146,13 @@ layout_type (tree type)
 
 case COMPLEX_TYPE:
   TYPE_UNSIGNED (type) = TYPE_UNSIGNED (TREE_TYPE (type));
-  SET_TYPE_MODE (type,
-mode_for_size (2 * TYPE_PRECISION (TREE_TYPE (type)),
-   (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE
-? MODE_COMPLEX_FLOAT : MODE_COMPLEX_INT),
-0));
+
+  /* build_complex_type and fortran's gfc_build_complex_type have set the
+expected mode to allow having