Re: [PATCH], Add optional IEEE/IBM long double multilib support

[Joseph Myers <joseph at codesourcery dot com>]

On Thu, 4 Jan 2018, Michael Meissner wrote:

> 	(CVT_FLOAT128_TO_IBM128): Use TFtype instead of __float128 to
> 	accomidate -mabi=ieeelongdouble multilibs.

Why is that correct in the -mabi=ibmlongdouble case?

As I understand it, TFtype is always of mode TFmode (it would certainly be 
confusing if it sometimes had a different mode), but TFmode's format 
depends on the selected ABI.  Where this code uses __float128, it requires 
something that is always of IEEE binary128 format.  In the 
-mabi=ieeelongdouble case, that's indeed TFtype, but not in the 
-mabi=ibmlongdouble case when TFmode has ibm128 format.

In C code, _Float128 and _Complex _Float128 should always be available 
when the binary128 format is supported, so I think the code needing that 
format can safely use those.

> 	(__mulkc3): Use TFmode/TCmode for float128 scalar/complex types.
> 	(__divkc3): Use TFmode/TCmode for float128 scalar/complex types.
> 	* config/rs6000/extendkftf2-sw.c (__extendkftf2_sw): Likewise.
> 	* config/rs6000/trunctfkf2-sw.c (__trunctfkf2_sw): Likewise.

And likewise here.

(My understanding is that each of the libgcc functions is meant to have a 
particular ABI that does not depend on the format of long double - so the 
"tf" and "tc" functions refer to ibm128 format, unconditionally, and the 
"kf" and "kc" ones to binary128 format, unconditionally.  I have not 
checked whether the libfuncs handling in init_float128_ibm and 
init_float128_ieee is sufficient to achieve this in all cases.  In 
particular, does complex arithmetic always use the correct one of "kc" and 
"tc" depending on the long double format?  What about __builtin_powil - 
does that properly use __powitf2 and __powikf2 as appropriate, or do you 
have the ABI of __powitf2 depending on the multilib?)

-- 
Joseph S. Myers
joseph@codesourcery.com