Re: [PATCH, 2 of 5], Add suport for PowerPC IEEE 128-bit floating point

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Tue, 15 Jul 2014, Michael Meissner wrote:

> These patches are the PowerPC specific patches to add IEEE 128-bit support to
> libgcc.  These patches need to be co-ordinated with the glibc support that
> provides the software floating point emulation.  The compiler patches need to
> be installed before these patches can be installed.
> 
> 2014-07-15  Michael Meissner  <meissner@linux.vnet.ibm.com>
> 
> 	* config.host (powerpc64*-*-linux*): Add t-float128 to PowerPC
> 	64-bit linux builds.

Testing for powerpc64*-*-linux* is not appropriate - remember that you can 
build for powerpc-linux-gnu --enable-targets=all and get 64-bit multilibs, 
and those should get exactly the same configuration as for a 64-bit 
multilib for powerpc64*-*-linux*.  Of course 32-bit multilibs should also 
get identical libgcc contents in both configurations (as far as I can 
tell, your intent does not include supporting the new type for 32-bit at 
present).

Various targets use tests of ${host_address} in config.host to condition 
aspects of the configuration on whether *the particular multilib being 
built* is 32-bit or 64-bit.  That's what you need to do here as well if 
you don't want both 32-bit and 64-bit to get the new functions.

> 	* config/rs6000/sfp-machine.h (_FP_W_TYPE_SIZE): On 64-bit
> 	systems, use 64-bit types instead of 32-bit types.
> 	(_FP_W_TYPE): Likewise.
> 	(_FP_WS_TYPE): Likewise.
> 	(_FP_I_TYPE): Likewise.
> 	(_FP_MUL_MEAT_Q): Likewise.
> 	(_FP_DIV_MEAT_Q): Likewise.
> 	(_FP_NANFRAC_Q): Likewise.
> 	(TItype): Define 128-bit integer types on 64-bit systems.
> 	(UTItype): Likewise.

This appears to be missing the integration with hardware exceptions and 
rounding modes that I noted in 
<https://gcc.gnu.org/ml/gcc-patches/2014-05/msg00105.html> should be 
included.

Also:

* There is no need for __sqrtkf2.  The __sqrt*2 functions in soft-fp never 
get used for anything; GCC will never generate calls to them.

* It seems to me there are some problems in the conversion from __float128 
to IBM long double.  If the high part of the result is Inf, you set low = 
high, but the low part of an infinity in IBM long double must be +/-0, not 
another infinity.  And when you do the subtraction to compute the low part 
of the result you seem to be missing the renormalization that I noted in 
<https://gcc.gnu.org/ml/gcc/2014-06/msg00033.html> would be needed.  I 
also don't understand what the sign bit manipulation is for; the low part 
(before renormalization) should be the result of the subtraction (whose 
sign may or may not be that of the high part), without any such 
manipulation.

-- 
Joseph S. Myers
joseph@codesourcery.com