public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails
@ 2021-06-16 22:00 seurer at gcc dot gnu.org
2021-07-08 21:25 ` [Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails patrick.mcgehearty at oracle dot com
` (13 more replies)
0 siblings, 14 replies; 15+ messages in thread
From: seurer at gcc dot gnu.org @ 2021-06-16 22:00 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
@ 2021-07-08 21:25 ` patrick.mcgehearty at oracle dot com
2021-07-20 22:46 ` [Bug target/101104] " segher at gcc dot gnu.org
` (12 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: patrick.mcgehearty at oracle dot com @ 2021-07-08 21:25 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
2021-07-08 21:25 ` [Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails patrick.mcgehearty at oracle dot com
@ 2021-07-20 22:46 ` segher at gcc dot gnu.org
2021-07-30 16:32 ` patrick.mcgehearty at oracle dot com
` (11 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: segher at gcc dot gnu.org @ 2021-07-20 22:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
2021-07-08 21:25 ` [Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails patrick.mcgehearty at oracle dot com
2021-07-20 22:46 ` [Bug target/101104] " segher at gcc dot gnu.org
@ 2021-07-30 16:32 ` patrick.mcgehearty at oracle dot com
2021-09-28 18:28 ` bergner at gcc dot gnu.org
` (10 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: patrick.mcgehearty at oracle dot com @ 2021-07-30 16:32 UTC (permalink / raw)
To: gcc-bugs
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.
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2021-07-30 16:32 ` patrick.mcgehearty at oracle dot com
@ 2021-09-28 18:28 ` bergner at gcc dot gnu.org
2021-09-29 18:13 ` patrick.mcgehearty at oracle dot com
` (9 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-09-28 18:28 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2021-09-28 18:28 ` bergner at gcc dot gnu.org
@ 2021-09-29 18:13 ` patrick.mcgehearty at oracle dot com
2021-09-29 19:04 ` bergner at gcc dot gnu.org
` (8 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: patrick.mcgehearty at oracle dot com @ 2021-09-29 18:13 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2021-09-29 18:13 ` patrick.mcgehearty at oracle dot com
@ 2021-09-29 19:04 ` bergner at gcc dot gnu.org
2021-09-29 21:46 ` bergner at gcc dot gnu.org
` (7 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-09-29 19:04 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2021-09-29 19:04 ` bergner at gcc dot gnu.org
@ 2021-09-29 21:46 ` bergner at gcc dot gnu.org
2021-09-29 23:40 ` patrick.mcgehearty at oracle dot com
` (6 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-09-29 21:46 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2021-09-29 21:46 ` bergner at gcc dot gnu.org
@ 2021-09-29 23:40 ` patrick.mcgehearty at oracle dot com
2021-09-30 0:53 ` bergner at gcc dot gnu.org
` (5 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: patrick.mcgehearty at oracle dot com @ 2021-09-29 23:40 UTC (permalink / raw)
To: gcc-bugs
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?
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2021-09-29 23:40 ` patrick.mcgehearty at oracle dot com
@ 2021-09-30 0:53 ` bergner at gcc dot gnu.org
2021-10-03 22:07 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-09-30 0:53 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2021-09-30 0:53 ` bergner at gcc dot gnu.org
@ 2021-10-03 22:07 ` cvs-commit at gcc dot gnu.org
2021-10-05 22:48 ` bergner at gcc dot gnu.org
` (3 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-10-03 22:07 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2021-10-03 22:07 ` cvs-commit at gcc dot gnu.org
@ 2021-10-05 22:48 ` bergner at gcc dot gnu.org
2021-10-06 16:32 ` segher at gcc dot gnu.org
` (2 subsequent siblings)
13 siblings, 0 replies; 15+ messages in thread
From: bergner at gcc dot gnu.org @ 2021-10-05 22:48 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2021-10-05 22:48 ` bergner at gcc dot gnu.org
@ 2021-10-06 16:32 ` segher at gcc dot gnu.org
2021-10-06 17:21 ` patrick.mcgehearty at oracle dot com
2021-10-06 18:56 ` segher at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: segher at gcc dot gnu.org @ 2021-10-06 16:32 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2021-10-06 16:32 ` segher at gcc dot gnu.org
@ 2021-10-06 17:21 ` patrick.mcgehearty at oracle dot com
2021-10-06 18:56 ` segher at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: patrick.mcgehearty at oracle dot com @ 2021-10-06 17:21 UTC (permalink / raw)
To: gcc-bugs
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?
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* [Bug target/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
` (12 preceding siblings ...)
2021-10-06 17:21 ` patrick.mcgehearty at oracle dot com
@ 2021-10-06 18:56 ` segher at gcc dot gnu.org
13 siblings, 0 replies; 15+ messages in thread
From: segher at gcc dot gnu.org @ 2021-10-06 18:56 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2021-10-06 18:56 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-16 22:00 [Bug testsuite/101104] New: test case g++.dg/tsan/pthread_cond_clockwait.C fails seurer at gcc dot gnu.org
2021-07-08 21:25 ` [Bug testsuite/101104] test case gcc.c-torture/execute/ieee/cdivchkld.c fails patrick.mcgehearty at oracle dot com
2021-07-20 22:46 ` [Bug target/101104] " segher at gcc dot gnu.org
2021-07-30 16:32 ` patrick.mcgehearty at oracle dot com
2021-09-28 18:28 ` bergner at gcc dot gnu.org
2021-09-29 18:13 ` patrick.mcgehearty at oracle dot com
2021-09-29 19:04 ` bergner at gcc dot gnu.org
2021-09-29 21:46 ` bergner at gcc dot gnu.org
2021-09-29 23:40 ` patrick.mcgehearty at oracle dot com
2021-09-30 0:53 ` bergner at gcc dot gnu.org
2021-10-03 22:07 ` cvs-commit at gcc dot gnu.org
2021-10-05 22:48 ` bergner at gcc dot gnu.org
2021-10-06 16:32 ` segher at gcc dot gnu.org
2021-10-06 17:21 ` patrick.mcgehearty at oracle dot com
2021-10-06 18:56 ` segher at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).