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