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

[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: meissner@linux.vnet.ibm.com, phone: +1 (978) 899-4797