I see I have more to learn about gcc's interactions with IEEE-128 format
vs IBM-128 format.
As we discovered here, using the IBM-128 version of LDBL_EPSILON will
not yield correct answers as currently coded.
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?
Do I need add a special case for
#ifndef __LONG_DOUBLE_IEEE128__
in the complex divide code in libgcc/libgcc2.c?
And, for completeness, does gcc support LDBL for non-IEEE on
any platform besides IBM?
- patrick
On 8/12/2021 11:47 AM, Joseph Myers wrote:
On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote:
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.
KFmode should always be IEEE binary128. IFmode should always be IBM long
double. TFmode may be one or the other depending on command-line options.
"in IBM128 mode" should mean that the compiler defaults to long double
being IBM long double and TFmode being IBM long double. But in that mode,
KFmode should still be IEEE binary128 and it should still be correct to
use the KF constants in this file.
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.
If built for IBM128 mode (i.e., compiler defaults to TFmode = IBM long
double), it should still build a function __divkc3 which takes IEEE
binary128 arguments and uses IEEE binary128 (KFmode) constants.
If you were changing the L_divtc3 case in libgcc2.c to use different
constants in the case where TFmode is IBM long double, that would make
sense to me. It's changing an IEEE-only file for an IBM long double issue
that doesn't make sense. If this change causes some test using IBM long
double to pass where it failed before, that indicates a build system
problem somewhere.
