To answer some of my own questions about how this works (or doesn't work): There are two different types in libgcc called TFtype, one in quad-float128.h and one in libgcc2.h. The one in quad-float128.h is mapped to KFmode in the case where TFmode is IBM long double, so functions such as __mulkc3 do get the correct types.
As far as I can tell, functions such as __multf3, and libgcc2.c TFmode functions in general, get the version of TFtype from libgcc2.h (which is always of mode TFmode). So I still don't see how you ensure all those functions do use IBM long double when IEEE long double is the default (but have not tested a build with IEEE long double as default). (And __powikf2 doesn't even exist, but is needed for __builtin_powil to work properly in the IEEE long double case.) I have confirmed with testing that _Complex long double multiplication with -mabi=ieeelongdouble still uses __multc3, although it needs to use __mulkc3, and, likewise, _Complex long double division with -mabi=ieeelongdouble wrongly uses __divtc3 but should be using __divkc3. -- Joseph S. Myers jos...@codesourcery.com