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 <meiss...@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
jos...@codesourcery.com
