The key code in _divkc3.c is:
#ifndef __LONG_DOUBLE_IEEE128__
#define RBIG (__LIBGCC_DF_MAX__ / 2)
#define RMIN (__LIBGCC_DF_MIN__)
#define RMIN2 (__LIBGCC_DF_EPSILON__)
#define RMINSCAL (1 / __LIBGCC_DF_EPSILON__)
#define RMAX2 (RBIG * RMIN2)
#else
#define RBIG (__LIBGCC_TF_MAX__ / 2)
#define RMIN (__LIBGCC_TF_MIN__)
#define RMIN2 (__LIBGCC_TF_EPSILON__)
#define RMINSCAL (1 / __LIBGCC_TF_EPSILON__)
#define RMAX2 (RBIG * RMIN2)
#endif
I added this code based on your comment of 4/20/2021:
---------
> This file includes quad-float128.h, which does some remapping from TF to
> KF depending on __LONG_DOUBLE_IEEE128__.
>
> I think you probably need to have a similar __LONG_DOUBLE_IEEE128__
> conditional here. If __LONG_DOUBLE_IEEE128__ is not defined, use
> __LIBGCC_KF_* macros instead of __LIBGCC_TF_*; if
__LONG_DOUBLE_IEEE128__
> is defined, use __LIBGCC_TF_* as above. (Unless the powerpc maintainers
> say otherwise.)
---------
The KF version fails when in IBM128 mode while the DF version works
for that mode.
My understanding of ibm FP mode build procedure is minimal,
but it seems that the _divkc3.c routine is built for both IEEE128
and IBM128 modes.
- patrick
On 8/12/2021 11:19 AM, Joseph Myers wrote:
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
This patch resolves the failure of powerpc64 long double complex divide
in native ibm long double format after the patch "Practical improvement
to libgcc complex divide".
This description is not consistent with the patch.
__divkc3 should always be using IEEE binary128 format, not IBM long
double. If this code is being built for IBM long double, something is
wrong somewhere else.
Using the DFmode values probably makes sense for IBM long double, but not
for IEEE binary128.
