This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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  <>
> 	* (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 

Various targets use tests of ${host_address} in 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 
<> should be 


* 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 
<> 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 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]