On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > If _divkc3.c is not intended to provide a version of complex divide > that handles IBM-128 format, then where should that option be handled?
That should be the function __divtc3. (A single libgcc binary supports multiple long double formats, so libgcc function names referring to floating-point modes need to be understood as actually referring to a particular *format*, which may or may not correspond to the named *mode* depending on the compilation options used. Thus, libgcc functions with "tf" or "tc" in their names, on configurations such as powerpc64le-linux-gnu that ever supported IBM long double, always refer to IBM long double. It's up to the back end to ensure that, when building with TFmode = binary128, TCmode and KCmode division both get mapped to __divkc3 while ICmode division gets mapped to __divtc3; when building with TFmode = IBM long double, KCmode division should still be __divkc3, ICmode division should still be __divtc3, and TCmode division should be __divtc3 in that case as well.) > Do I need add a special case for > #ifndef __LONG_DOUBLE_IEEE128__ > in the complex divide code in libgcc/libgcc2.c? That macro is architecture-specific so shouldn't be tested there. Doing things differently if __LIBGCC_TF_MANT_DIG__ == 106 would be reasonable (if it fixes the observed problem!), however; there are a few places in generic libgcc code that check for MANT_DIG == 106 to handle IBM long double differently. > And, for completeness, does gcc support LDBL for non-IEEE on > any platform besides IBM? I believe TFmode is IEEE binary128 everywhere except for those powerpc configurations where it's IBM long double. -- Joseph S. Myers jos...@codesourcery.com
