[Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails

[Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails

[seurer at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

            Bug ID: 101104
           Summary: test case g++.dg/tsan/pthread_cond_clockwait.C fails
           Product: gcc
           Version: 12.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: testsuite
          Assignee: unassigned at gcc dot gnu.org
          Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:54f0224d55a1b56dde092460ddf76913670e6efc, r12-228 

These have not worked right on powerpc64 since they were introduced.

FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os
FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os


commit 54f0224d55a1b56dde092460ddf76913670e6efc
Author: Patrick McGehearty <patrick.mcgehearty@oracle.com>
Date:   Wed Apr 28 19:14:48 2021 +0000

    Practical improvement to libgcc complex divide

[Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

Patrick McGehearty <patrick.mcgehearty at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |patrick.mcgehearty at oracle dot c
                   |                            |om

--- Comment #1 from Patrick McGehearty <patrick.mcgehearty at oracle dot com> ---
I identified the root cause as not fully understanding the IBM native format.
The gcc internal representation uses KF mode for IBM 128-bit floating point. It
uses
DF mode for all 64-bit floating point.

When KF mode is used, the value for LDBL_EPSILON is 0x1.0p-1074 and RMINSCAL=
1/LDBL_EPSILON is infinity. Then all input values which trigger scaling
will overflow to infinity which of course fails the test.

Switching the constants to use DF instead of KF resolves the overflow issue
without significantly changing the usefulness of the new method. That's because
DF and KF mode use the same number of bits for the exponent, allowing MAX and
MIN to be nearly identical.

The patch is being submitted to gcc-patches@gcc.gnu.org now.

The fix only requires changes to one file:
libgcc/config/rs6000/_divkc3.c

diff --git a/libgcc/config/rs6000/_divkc3.c b/libgcc/config/rs6000/_divkc3.c
index a1d29d2..2b229c8 100644
--- a/libgcc/config/rs6000/_divkc3.c
+++ b/libgcc/config/rs6000/_divkc3.c
@@ -38,10 +38,10 @@ see the files COPYING3 and COPYING.RUNTIME respectively. 
If
not, see
 #endif

 #ifndef __LONG_DOUBLE_IEEE128__
-#define RBIG   (__LIBGCC_KF_MAX__ / 2)
-#define RMIN   (__LIBGCC_KF_MIN__)
-#define RMIN2  (__LIBGCC_KF_EPSILON__)
-#define RMINSCAL (1 / __LIBGCC_KF_EPSILON__)
+#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)

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

Segher Boessenkool <segher at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |segher at gcc dot gnu.org
          Component|testsuite                   |target

--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Patrick McGehearty from comment #1)
> I identified the root cause as not fully understanding the IBM native
> format. The gcc internal representation uses KF mode for IBM 128-bit
> floating point.

KFmode is IEEE QP float.  IFmode is double-double, "IBM extended double",
a pair of DP float numbers (with some rules, not every pair is valid).

TFmode is one of those.

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #3 from Patrick McGehearty <patrick.mcgehearty at oracle dot com> ---
I meant to say "IF mode" instead of KF mode.
Shall I resubmit with that correction?

- patrick

On 7/20/2021 5:46 PM, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
>
> Segher Boessenkool <segher at gcc dot gnu.org> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |segher at gcc dot gnu.org
>            Component|testsuite                   |target
>
> --- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> (In reply to Patrick McGehearty from comment #1)
>> I identified the root cause as not fully understanding the IBM native
>> format. The gcc internal representation uses KF mode for IBM 128-bit
>> floating point.
> KFmode is IEEE QP float.  IFmode is double-double, "IBM extended double",
> a pair of DP float numbers (with some rules, not every pair is valid).
>
> TFmode is one of those.
>

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bergner at gcc dot gnu.org

--- Comment #4 from Peter Bergner <bergner at gcc dot gnu.org> ---
So what is the status here?  Are we just waiting for another patch to be
submitted or it has been submitted and we're waiting on a review?

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #5 from Patrick McGehearty <patrick.mcgehearty at oracle dot com> ---
(In reply to Peter Bergner from comment #4)
> So what is the status here?  Are we just waiting for another patch to be
> submitted or it has been submitted and we're waiting on a review?

I submitted a patch that I believe resolves the issue on Aug 27, 2021
and pinged the gcc-patches list on Sept 8, 2021. Allowing for the
'distraction' of Linux Plumbers conference last week, I'm hoping
someone will try out my patch on a modern rs6000 environment to
confirm it works as expected.

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #6 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Patrick McGehearty from comment #5)
> I submitted a patch that I believe resolves the issue on Aug 27, 2021
> and pinged the gcc-patches list on Sept 8, 2021. Allowing for the
> 'distraction' of Linux Plumbers conference last week, I'm hoping
> someone will try out my patch on a modern rs6000 environment to
> confirm it works as expected.

Ah, the v5 patch.  I'll bootstrap and regtest the patch and report back. 
Thanks!

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Peter Bergner from comment #6)
> Ah, the v5 patch.  I'll bootstrap and regtest the patch and report back. 

Building with and without the patch, I'm seeing:

+FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O0 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fno-use-linker-plugin -flto-partition=none 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-fu
nctions 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g 
+FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Og -g 
 FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os 

So 2 new FAILs and no new PASSes with the patch. :-(
Is there anything you want me to check?

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #8 from Patrick McGehearty <patrick.mcgehearty at oracle dot com> ---
Thanks for the run.

On the plus side, I would expect FAIL or PASS to be consistent
for all optimization levels, so that's actually good that
they all match now.

I'm either I'm mistaken about the root cause of the failure
or I've made some goof in my fix.

... break to reexamine the tests I did...

got back on gcc135.fsffrance.org and looked carefully at the
tests I ran.  I see where I went wrong. In my manual testing,
I set RBIG, RMIN, RMIN2, RMINSCAL and RMAX2 all to double
precision values instead of long double precision values.
When I modified the libgcc2.c file, I only changed the
RMINSCAL and RMAX2 (which depended DBL_EPSILON).
I just created and ran a new manual test which only changes
RMINSCAL and RMAX2. It fails. Oops...
I'm pretty sure of the fix, but I will take the time to be
careful and submit a revised patch (V6) soon.

My challenge is that the very old glibc on gcc135.fsffrance.org
does not know about _TF_ vs _KF_ and _IF_. It refused to
build the new libgcc/config/rs6000/_divkc3.c file.
That's why I did not test the result in place.

It just occurred to me that if I remove _KF_ references in that
file and build a test compiler, that will give me a way to
test the ibm doubledouble code generated by libgcc/libgcc2.c

Thanks again for helping this fix move forward.

- patrick




On 9/29/2021 4:46 PM, bergner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
>
> --- Comment #7 from Peter Bergner <bergner at gcc dot gnu.org> ---
> (In reply to Peter Bergner from comment #6)
>> Ah, the v5 patch.  I'll bootstrap and regtest the patch and report back.
> Building with and without the patch, I'm seeing:
>
> +FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O0
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O1
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
> -fno-use-linker-plugin -flto-partition=none
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3
> -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-fu
> nctions
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -O3 -g
> +FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Og -g
>   FAIL: gcc.c-torture/execute/ieee/cdivchkld.c execution,  -Os
>
> So 2 new FAILs and no new PASSes with the patch. :-(
> Is there anything you want me to check?
>

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #9 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Patrick McGehearty from comment #8)
> Thanks again for helping this fix move forward.

If you have another patch you want me to test, just send it to me and I'll kick
it off.

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jeff Law <law@gcc.gnu.org>:

https://gcc.gnu.org/g:d91056851c5c60f226e3192fb955d018b53eb66f

commit r12-4104-gd91056851c5c60f226e3192fb955d018b53eb66f
Author: Patrick McGehearty <patrick.mcgehearty@oracle.com>
Date:   Sun Oct 3 18:07:06 2021 -0400

    Fix for powerpc64 long double complex divide failure

    - - - -

    New in version 6: Due to an oversight (i.e. coding error), version 5
    changed the use of __LIBGCC_TF_EPSILON__ to __LIBGCC_DF_EPSILON__ but
    not the other LIBGCC_TF values. For correct execution of the long
    double test case it is necessary to also switch to using
    __LIBGCC_DF_MIN__. For consistency we also switch to using
    __LIBGCC_DF_MAX__. LDBL_MIN is 2**53 times as larger than DBL_MIN.
    The larger value causes the code to switch the order of computation
    when it is not optimal, resulting in failure for one of the values
    in the cdivchk_ld.c test. Using DBL_MIN does not cause that failure..

    There may be opportunity for further refinement of IBM128 format
    Long Double complex divide, but that's beyond the scope of this
    patch.

    - - - -

    This revision adds a test in libgcc/libgcc2.c for when
    "__LIBGCC_TF_MANT_DIG__ == 106" to use __LIBGCC_DF_EPSILON__ instead
    of __LIBGCC_TF_EPSILON__. That is specific to IBM 128-bit format long
    doubles where EPSILON is very, very small and 1/EPSILON oveflows to
    infinity. This change avoids the overflow without affecting any other
    platform. Discussion in the patch is adjusted to reflect this
    limitation.

    It does not make any changes to .../rs6000/_divkc3.c, leaving it to
    use __LIBGCC_KF__*. That means the upstream gcc will not build in
    older IBM environments that do not recognize the KF floating point
    mode properly. Environments that do not need IBM longdouble support
    do build cleanly.

    - - - -
    This patch addresses the failure of powerpc64 long double complex divide
    in native ibm long double format after the patch "Practical improvement
    to libgcc complex divide".

    The new code uses the following macros which are intended to be mapped
    to appropriate values according to the underlying hardware representation.
    See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

    RBIG     a value near the maximum representation
    RMIN     a value near the minimum representation
             (but not in the subnormal range)
    RMIN2    a value moderately less than 1
    RMINSCAL the inverse of RMIN2
    RMAX2    RBIG * RMIN2  - a value to limit scaling to not overflow

    When "long double" values were not using the IEEE 128-bit format but
    the traditional IBM 128-bit, the previous code used the LDBL values
    which caused overflow for RMINSCAL. The new code uses the DBL values.

    RBIG  LDBL_MAX = 0x1.fffffffffffff800p+1022
          DBL_MAX  = 0x1.fffffffffffff000p+1022

    RMIN  LDBL_MIN = 0x1.0000000000000000p-969
    RMIN  DBL_MIN  = 0x1.0000000000000000p-1022

    RMIN2 LDBL_EPSILON = 0x0.0000000000001000p-1022 = 0x1.0p-1074
    RMIN2 DBL_EPSILON  = 0x1.0000000000000000p-52

    [ORMINSCAL 1/LDBL_EPSILON = inf (1.0p+1074 does not fit in IBM 128-bit).
             1/DBL_EPSILON  = 0x1.0000000000000000p+52

    RMAX2 = RBIG * RMIN2 = 0x1.fffffffffffff800p-52
            RBIG * RMIN2 = 0x1.fffffffffffff000p+970

    The MAX and MIN values have only modest changes since the maximum and
    minimum values are about the same as for double precision.  The
    EPSILON field is considerably different. Due to how very small values
    can be represented in the lower 64 bits of the IBM 128-bit floating
    point, EPSILON is extremely small, so far beyond the desired value
    that inversion of the value overflows and even without the overflow,
    the RMAX2 is so small as to eliminate most usage of the test.

    The change has been tested on gcc135.fsffrance.org and gains the
    expected improvements in accuracy for long double complex divide.

    libgcc/
            PR target/101104
            * libgcc2.c (RMIN2, RMINSCAL, RMAX2):
            Use more correct values for native IBM 128-bit.

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[bergner at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #11 from Peter Bergner <bergner at gcc dot gnu.org> ---
Bill confirmed these are now fixed.  Thanks for the fix Patrick!

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Patrick McGehearty from comment #8)
> My challenge is that the very old glibc on gcc135.fsffrance.org
> does not know about _TF_ vs _KF_ and _IF_. It refused to
> build the new libgcc/config/rs6000/_divkc3.c file.
> That's why I did not test the result in place.

The glibc on gcc135 is not older than the oldest supported version, so your
code should work just fine there.  Or do you mean this is not supported and
configure makes sure this is not built?

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[patrick.mcgehearty at oracle dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #13 from Patrick McGehearty <patrick.mcgehearty at oracle dot com> ---
I may be mistaken about the source of the issue being glibc.
Perhaps it is a system include file issue? Here are some
more details.

Here are some of the error messages I got when building with
__LIBGCC_KF_MAX__ of gcc135.fsffrance.org using the installed
gcc (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC))

- - - - - -
../../../libgcc/config/rs6000/_divkc3.c: In function ‘__divkc3’:
../../../libgcc/config/rs6000/_divkc3.c:41:17: error: 
‘__LIBGCC_KF_MAX__’ undeclared (first use in this function)
    41 | #define RBIG   (__LIBGCC_KF_MAX__ / 2)
       |                 ^~~~~~~~~~~~~~~~~
../../../libgcc/config/rs6000/_divkc3.c:68:23: note: in expansion of 
macro ‘RBIG’
    68 |       if (FABS (d) >= RBIG)
       |                       ^~~~
... repeated for ‘__LIBGCC_KF_EPSILON__ and __LIBGCC_KF_MIN__
- - - - - -

__LIBGCC_KF_MAX__ should have been defined in the file 
gcc/c-family/c-cppbuiltin.c
in the loop starting at line 1274:
       /* Properties of floating-point modes for libgcc2.c.  */
       opt_scalar_float_mode mode_iter;
       FOR_EACH_MODE_IN_CLASS (mode_iter, MODE_FLOAT)
         {
           scalar_float_mode mode = mode_iter.require ();
...

My guess is that however the modes are defined for a given 
platform/compile option
combination, KF is not available with this particular compiler/glibc 
combination.
I did some digging in the latest sources and could not find a specific file
which defined KF, TF, IF, etc. I assume it exists and I just did not 
look in the
right places.

I did try setting my path to pick up a current upstream gcc 
(PATH=~/usr/bin:$PATH; export PATH).
It did not make a significant difference in the error message.

In any case, it is moot since Joseph Myers stated that I should not 
include the
"if compiling for ibm doubledouble" code in _divkc3.c because _divkc3.c 
is only
used for ieee128 code. Since he is the one who guided me in my changes 
to c-cppbuiltin.c,
I assume he knows more than I on this topic.

- patrick



On 10/6/2021 11:32 AM, segher at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
>
> --- Comment #12 from Segher Boessenkool <segher at gcc dot gnu.org> ---
> (In reply to Patrick McGehearty from comment #8)
>> My challenge is that the very old glibc on gcc135.fsffrance.org
>> does not know about _TF_ vs _KF_ and _IF_. It refused to
>> build the new libgcc/config/rs6000/_divkc3.c file.
>> That's why I did not test the result in place.
> The glibc on gcc135 is not older than the oldest supported version, so your
> code should work just fine there.  Or do you mean this is not supported and
> configure makes sure this is not built?
>

[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104

--- Comment #14 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Patrick McGehearty from comment #13)
> I may be mistaken about the source of the issue being glibc.
> Perhaps it is a system include file issue? Here are some
> more details.
> 
> Here are some of the error messages I got when building with
> __LIBGCC_KF_MAX__ of gcc135.fsffrance.org using the installed
> gcc (gcc version 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC))
> 
> - - - - - -
> ../../../libgcc/config/rs6000/_divkc3.c: In function ‘__divkc3’:
> ../../../libgcc/config/rs6000/_divkc3.c:41:17: error: 
> ‘__LIBGCC_KF_MAX__’ undeclared (first use in this function)
>     41 | #define RBIG   (__LIBGCC_KF_MAX__ / 2)
>        |                 ^~~~~~~~~~~~~~~~~
> ../../../libgcc/config/rs6000/_divkc3.c:68:23: note: in expansion of 
> macro ‘RBIG’
>     68 |       if (FABS (d) >= RBIG)
>        |                       ^~~~
> ... repeated for ‘__LIBGCC_KF_EPSILON__ and __LIBGCC_KF_MIN__
> - - - - - -

This is defined be GCC itself.  But not in the configuration you built.
This requires VSX (currently).

The problem is in the _divkc3.c code.

> __LIBGCC_KF_MAX__ should have been defined in the file 
> gcc/c-family/c-cppbuiltin.c
> in the loop starting at line 1274:
>        /* Properties of floating-point modes for libgcc2.c.  */
>        opt_scalar_float_mode mode_iter;
>        FOR_EACH_MODE_IN_CLASS (mode_iter, MODE_FLOAT)
>          {
>            scalar_float_mode mode = mode_iter.require ();

The mode does not exist in this config.  The macro should not have been
defined.

> KF is not available with this particular compiler/glibc 
> combination.

KF is not available if you use -mno-vsx.  This is the default in most
configurations.

> I did some digging in the latest sources and could not find a specific file
> which defined KF, TF, IF, etc. I assume it exists and I just did not 
> look in the
> right places.

rs6000-modes.def .  You need TARGET_FLOAT128_TYPE set to be able to use it;
you normally get

  TARGET_FLOAT128_TYPE = TARGET_FLOAT128_ENABLE_TYPE && TARGET_VSX;

> In any case, it is moot since Joseph Myers stated that I should not 
> include the
> "if compiling for ibm doubledouble" code in _divkc3.c because _divkc3.c 
> is only
> used for ieee128 code. Since he is the one who guided me in my changes 
> to c-cppbuiltin.c,
> I assume he knows more than I on this topic.

Ah :-)  That is essential context.  I did not know you hadn't done this yet.