Re: [PATCH v3] Fix for powerpc64 long double complex divide failure

[Joseph Myers <joseph@codesourcery.com>]

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