On Tue, 3 Jun 2014, Vincent Lefevre wrote:
> On 2014-06-02 21:20:57 +, Joseph S. Myers wrote:
> > ([...] Conversion from __float128 to __ibm128 would presumably be
> > done in the usual way of converting to double, and, if the result is
> > finite, subtracting the double from the __float128 va
On 2014-06-02 21:20:57 +, Joseph S. Myers wrote:
> ([...] Conversion from __float128 to __ibm128 would presumably be
> done in the usual way of converting to double, and, if the result is
> finite, subtracting the double from the __float128 value, converting
> the remainder, and renormalizing i
On Fri, 30 May 2014, Michael Meissner wrote:
> One issue is the current mode setup is when you create new floating point
> types, the widening system kicks in and the compiler will generate all sorts
> of
> widening from one 128-bit floating point format to another (because internally
> the preci
Currently within the GCC rs6000 backend, the type TFmode is the default 128-bit
floating point type. Depending on TARGET_IEEEQUAD (the internal name for the
-mabi=ieeelongdouble option), this gets mapped into either the IEEE 128-bit
format or the IBM extended double format. In theory, any place t
