[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104
--- Comment #13 from Patrick McGehearty
---
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 ---
> (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 --- Comment #8 from Patrick McGehearty --- 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 --- > (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 --- Comment #5 from Patrick McGehearty --- (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 libgcc/59714] complex division is surprising on targets with FMA (was: on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 --- Comment #11 from Patrick McGehearty --- Thanks! On 9/9/2021 5:54 PM, pinskia at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 > > --- Comment #10 from Andrew Pinski --- > (In reply to Patrick McGehearty from comment #9) > r12-228-g54f0224d55a1b56dde092460ddf76913670e6efc > > Just making it easier for links here. >
[Bug libgcc/59714] complex division is surprising on targets with FMA (was: on aarch64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59714 Patrick McGehearty changed: What|Removed |Added CC||patrick.mcgehearty at oracle dot c ||om --- Comment #9 from Patrick McGehearty --- The patch 54f0224d55a1b56dde092460ddf76913670e6efc "Practical improvement to libgcc complex divide" made substantial improvements to the algorithms used and thus the accuracy of complex divide for IEEE-754 precisions for half, float, double, and long-double precision. In particular, when examining randomly generated values uniformly distributed over the full exponent range, 2 bit errors dropped from 1.88% to less than one in 10,000. The particular input values discussed in this problem report no longer show any errors whether or not FMA is used. See the patch for more complete details.
[Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 --- Comment #3 from Patrick McGehearty --- 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 changed: > > What|Removed |Added > > CC||segher at gcc dot gnu.org >Component|testsuite |target > > --- Comment #2 from Segher Boessenkool --- > (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 testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101104 Patrick McGehearty changed: What|Removed |Added CC||patrick.mcgehearty at oracle dot c ||om --- Comment #1 from Patrick McGehearty --- 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-patc...@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)
