* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
@ 2022-08-10 17:51 ` jakub at gcc dot gnu.org
2022-08-10 22:46 ` segher at gcc dot gnu.org
` (13 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-10 17:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |fxcoudert at gcc dot gnu.org,
| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ouch, indeed.
Looking at ieee/ieee_exceptions.F90, I think that one is ok, while
__ieee_exceptions_MOD_ieee_support_flag_16
is exported from the library, all of
__ieee_exceptions_MOD_ieee_support_flag_{4,8,16} return the same result and I
think it is the same for both IEEE quad and IBM double double formats too,
so using __ieee_exceptions_MOD_ieee_support_flag_16 for it is fine.
On the other side, ieee/ieee_arithmetic.F90 is problematic.
I must say I don't understand at all stuff like IEEE_IS_FINITE, because it
refers
to stuff like _gfortran_ieee_is_finite_16 which I don't see anywhere in
libgfortran.{so.5,a}.
Looking purely on what is exported from libgfortran.so.5 from the
ieee_arithmetic module symbols, I see:
readelf -Wa ../powerpc64le-unknown-linux-gnu/libgfortran/.libs/libgfortran.so.5
| grep ieee_arith | grep _16@@
483: 00000000001ca770 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_io_16@@GFORTRAN_8
555: 00000000001ca670 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_sqrt_16@@GFORTRAN_8
753: 00000000001cac10 72 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_rounding_16@@GFORTRAN_8 [<localentry>: 8]
771: 00000000001caef0 56 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_class_16@@GFORTRAN_8 [<localentry>: 8]
795: 00000000001ca8f0 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_subnormal_16@@GFORTRAN_9
823: 00000000001ca970 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_denormal_16@@GFORTRAN_8
961: 00000000001ca6f0 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_nan_16@@GFORTRAN_8
1220: 00000000001cae30 60 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_value_16@@GFORTRAN_8 [<localentry>: 8]
1265: 00000000001ca7f0 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_inf_16@@GFORTRAN_8
1502: 00000000001caad0 72 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_underflow_control_16@@GFORTRAN_8
[<localentry>: 8]
1532: 00000000001ca5f0 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_standard_16@@GFORTRAN_8
1596: 00000000001ca870 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_divide_16@@GFORTRAN_8
1703: 00000000001ca9f0 20 FUNC GLOBAL DEFAULT 11
__ieee_arithmetic_MOD_ieee_support_datatype_16@@GFORTRAN_8
Now, most of the above are probably fine too, they just return true and again
that answer seems to be fine for both when
real(kind=16) is IBM double double or IEEE quad.
The problematic cases from those are:
__ieee_arithmetic_MOD_ieee_class_16
__ieee_arithmetic_MOD_ieee_value_16
The above 2 clearly need different behavior when real(kind=16) is IEEE quad vs.
IBM double double, the
implementation right now implements those for IBM double double.
So, either we need to arrange for those to be expanded inline by the frontend
(and it can be done either
by hardcoding the enumerators or say transforming the calls from working with
IEEE quad to working with
IBM double double or vice versa), or we need to add
__ieee_arithmetic_MOD_ieee_class_17
__ieee_arithmetic_MOD_ieee_value_17
entrypoints to the library and arrange for the _16 to be remapped to _17 for
these 2.
Other possibly problematic functions are
__ieee_arithmetic_MOD_ieee_support_rounding_16
__ieee_arithmetic_MOD_ieee_support_underflow_control_16
The former seems to do the exact same call in each case, so is probably fine
like the true cases,
the latter actually calls support_underflow_control_helper with kind value, but
it is ignored everywhere but alpha,
so is fine too.
For the transformation above, I mean something like handling ieee_class by
doing __builtin_fpclassify + issignalling
and __builtin_signbit and depending on the result call
__ieee_arithmetic_MOD_ieee_class_16 on sample IBM double double
values with the same properties.
Similarly, ieee_value by calling __ieee_arithmetic_MOD_ieee_value_16 first,
analyzing the result with
__builtin_fpclassify and in most cases just converting the IBM double double to
IEEE quad.
Guess NaNs (especially signalling NaN) and denormals need to be an exception.
Another question is if one needs to implement these as actual out of line
functions (even hidden), whether it is
permissible to say call some function/subroutine with ieee_value or ieee_class
as procedure argument.
Given that they are overloaded, I'd hope it is not possible.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
2022-08-10 17:51 ` [Bug fortran/106579] " jakub at gcc dot gnu.org
@ 2022-08-10 22:46 ` segher at gcc dot gnu.org
2022-08-11 7:52 ` fxcoudert at gcc dot gnu.org
` (12 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: segher at gcc dot gnu.org @ 2022-08-10 22:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Segher Boessenkool <segher at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |segher at gcc dot gnu.org
--- Comment #2 from Segher Boessenkool <segher at gcc dot gnu.org> ---
Let me say again that IEEE QP and double-double should not be the same kind.
This very obviously cannot work at all.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
2022-08-10 17:51 ` [Bug fortran/106579] " jakub at gcc dot gnu.org
2022-08-10 22:46 ` segher at gcc dot gnu.org
@ 2022-08-11 7:52 ` fxcoudert at gcc dot gnu.org
2022-08-11 9:55 ` jakub at gcc dot gnu.org
` (11 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2022-08-11 7:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #3 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
The module in the runtime library is compiled only once, unless the library is
multilib (one libgfortran compiled for IBM double double, one libgfortran
compiled for IEEE quad).
My goal would be to generate all IEEE intrinsics in the front-end, it should be
possible. However, there is not enough support in the middle-end support at the
current time: one would need to have GCC support type-generic built-ins for the
various IEEE fp functions. This was discussed, there was even a patch at some
point for some of them (there must be some discussion of this between myself
and, I think, Richard Biener on the gcc list a couple of months ago, but I
can't find it right now).
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2022-08-11 7:52 ` fxcoudert at gcc dot gnu.org
@ 2022-08-11 9:55 ` jakub at gcc dot gnu.org
2022-08-11 11:26 ` fxcoudert at gcc dot gnu.org
` (10 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-11 9:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Ok, I'll first implement __builtin_issignaling and then
conv_intrinsic_ieee_{value,class}.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2022-08-11 9:55 ` jakub at gcc dot gnu.org
@ 2022-08-11 11:26 ` fxcoudert at gcc dot gnu.org
2022-08-11 16:22 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: fxcoudert at gcc dot gnu.org @ 2022-08-11 11:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed| |2022-08-11
--- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> ---
Previous discussion on the list:
- when I first implemented it in 2013:
https://gcc.gnu.org/legacy-ml/gcc/2013-11/msg00109.html
- more recent: https://www.mail-archive.com/gcc@gcc.gnu.org/msg97340.html
I think Joseph pointed (either in another bugzilla issue, or on the list) to a
first tentative implementation of __builtin_issignaling in the middle-end by
Sandra Loosemore, which had to be reversed because it caused trouble on some
targets. The difficulty that was cited (and why I didn't get to it myself) is
the large number of floating-point formats to be handled.
That said, having __builtin_issignaling() would be great and we could emit a
lot more of the IEEE functions in the front-end, if it were available.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2022-08-11 11:26 ` fxcoudert at gcc dot gnu.org
@ 2022-08-11 16:22 ` jakub at gcc dot gnu.org
2022-08-11 20:35 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-11 16:22 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53438&action=edit
gcc13-builtin-issignaling.patch
Current WIP on the __builtin_issignaling.
Still need to look at decimal arguments (if we need/want to deal with those)
and add i386 issignalingxf2 optab so that it also handles pseudo numbers and
add test coverage.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2022-08-11 16:22 ` jakub at gcc dot gnu.org
@ 2022-08-11 20:35 ` jakub at gcc dot gnu.org
2022-08-12 11:19 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-11 20:35 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #53438|0 |1
is obsolete| |
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53440
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53440&action=edit
gcc13-builtin-issignaling.patch
Another WIP version, the i386.md expander needs some more work but otherwise it
looks good on x86_64/i686.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (6 preceding siblings ...)
2022-08-11 20:35 ` jakub at gcc dot gnu.org
@ 2022-08-12 11:19 ` jakub at gcc dot gnu.org
2022-08-12 17:15 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-12 11:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #53440|0 |1
is obsolete| |
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53444
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53444&action=edit
gcc13-builtin-issignaling.patch
This one works on x86_64/i686, now to test ppc64le and ppc64.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (7 preceding siblings ...)
2022-08-12 11:19 ` jakub at gcc dot gnu.org
@ 2022-08-12 17:15 ` jakub at gcc dot gnu.org
2022-08-26 7:53 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-12 17:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53448
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53448&action=edit
gcc13-pr106579.patch
On top of that, this implements ieee_class. ieee_value still to be
implemented.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (8 preceding siblings ...)
2022-08-12 17:15 ` jakub at gcc dot gnu.org
@ 2022-08-26 7:53 ` cvs-commit at gcc dot gnu.org
2022-08-26 7:56 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-08-26 7:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:db630423a97ec6690a8eb0e5c3cb186c91e3740d
commit r13-2216-gdb630423a97ec6690a8eb0e5c3cb186c91e3740d
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Aug 26 09:52:02 2022 +0200
fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]
The following patch expands IEEE_CLASS inline in the FE, using the
__builtin_fpclassify, __builtin_signbit and the new __builtin_issignaling
builtins.
2022-08-26 Jakub Jelinek <jakub@redhat.com>
PR fortran/106579
gcc/fortran/
* f95-lang.cc (gfc_init_builtin_functions): Initialize
BUILT_IN_FPCLASSIFY.
* libgfortran.h (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
New enum.
* trans-intrinsic.cc (conv_intrinsic_ieee_class): New function.
(gfc_conv_ieee_arithmetic_function): Handle ieee_class.
libgfortran/
* ieee/ieee_helper.c (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
Move to gcc/fortran/libgfortran.h.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (9 preceding siblings ...)
2022-08-26 7:53 ` cvs-commit at gcc dot gnu.org
@ 2022-08-26 7:56 ` cvs-commit at gcc dot gnu.org
2022-08-26 8:05 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-08-26 7:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:0c2d6aa1be2ea85e751852834986ae52d58134d3
commit r13-2217-g0c2d6aa1be2ea85e751852834986ae52d58134d3
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Aug 26 09:56:19 2022 +0200
fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]
The following patch expands IEEE_VALUE function inline in the FE.
2022-08-26 Jakub Jelinek <jakub@redhat.com>
PR fortran/106579
* trans-intrinsic.cc: Include realmpfr.h.
(conv_intrinsic_ieee_value): New function.
(gfc_conv_ieee_arithmetic_function): Handle ieee_value.
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (10 preceding siblings ...)
2022-08-26 7:56 ` cvs-commit at gcc dot gnu.org
@ 2022-08-26 8:05 ` jakub at gcc dot gnu.org
2022-08-29 10:06 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-26 8:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk now. Not really sure what to do for the backport. Perhaps
make the builtin with a space in the name and do the FE expansion only for the
abi_kind == 17 cases?
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (11 preceding siblings ...)
2022-08-26 8:05 ` jakub at gcc dot gnu.org
@ 2022-08-29 10:06 ` cvs-commit at gcc dot gnu.org
2022-08-29 10:06 ` cvs-commit at gcc dot gnu.org
2022-08-30 9:10 ` jakub at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-08-29 10:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #13 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:c5d4e67e764fb157404142cfc8d2bc4436fcf0f5
commit r12-8723-gc5d4e67e764fb157404142cfc8d2bc4436fcf0f5
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Aug 26 09:52:02 2022 +0200
fortran: Expand ieee_arithmetic module's ieee_class inline [PR106579]
The following patch expands IEEE_CLASS inline in the FE but only for the
powerpc64le-linux IEEE quad real(kind=16), using the __builtin_fpclassify
builtin and explicit check of the MSB mantissa bit in place of missing
__builtin_signbit builtin.
2022-08-26 Jakub Jelinek <jakub@redhat.com>
PR fortran/106579
gcc/fortran/
* f95-lang.cc (gfc_init_builtin_functions): Initialize
BUILT_IN_FPCLASSIFY.
* libgfortran.h (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
New enum.
* trans-intrinsic.cc (conv_intrinsic_ieee_class): New function.
(gfc_conv_ieee_arithmetic_function): Handle ieee_class.
libgfortran/
* ieee/ieee_helper.c (IEEE_OTHER_VALUE, IEEE_SIGNALING_NAN,
IEEE_QUIET_NAN, IEEE_NEGATIVE_INF, IEEE_NEGATIVE_NORMAL,
IEEE_NEGATIVE_DENORMAL, IEEE_NEGATIVE_SUBNORMAL,
IEEE_NEGATIVE_ZERO, IEEE_POSITIVE_ZERO, IEEE_POSITIVE_DENORMAL,
IEEE_POSITIVE_SUBNORMAL, IEEE_POSITIVE_NORMAL, IEEE_POSITIVE_INF):
Move to gcc/fortran/libgfortran.h.
(cherry picked from commit db630423a97ec6690a8eb0e5c3cb186c91e3740d)
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (12 preceding siblings ...)
2022-08-29 10:06 ` cvs-commit at gcc dot gnu.org
@ 2022-08-29 10:06 ` cvs-commit at gcc dot gnu.org
2022-08-30 9:10 ` jakub at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-08-29 10:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
--- Comment #14 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:87a07e96dc4e6849ab6ac0b1ceeb5a19aebee9d6
commit r12-8724-g87a07e96dc4e6849ab6ac0b1ceeb5a19aebee9d6
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Aug 26 09:56:19 2022 +0200
fortran: Expand ieee_arithmetic module's ieee_value inline [PR106579]
The following patch expands IEEE_VALUE function inline in the FE,
but only for the powerpc64le-linux IEEE quad real(kind=16) case.
2022-08-26 Jakub Jelinek <jakub@redhat.com>
PR fortran/106579
* trans-intrinsic.cc: Include realmpfr.h.
(conv_intrinsic_ieee_value): New function.
(gfc_conv_ieee_arithmetic_function): Handle ieee_value.
(cherry picked from commit 0c2d6aa1be2ea85e751852834986ae52d58134d3)
^ permalink raw reply [flat|nested] 16+ messages in thread* [Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64
2022-08-10 15:14 [Bug fortran/106579] New: ieee_signaling_nan problem in fortran on powerpc64 seurer at gcc dot gnu.org
` (13 preceding siblings ...)
2022-08-29 10:06 ` cvs-commit at gcc dot gnu.org
@ 2022-08-30 9:10 ` jakub at gcc dot gnu.org
14 siblings, 0 replies; 16+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-08-30 9:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106579
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed also for GCC 12 by inlining in that case only the IEEE quad real(kind)
ieee_{class,value} and just checking a single bit instead of using
__builtin_issignaling.
^ permalink raw reply [flat|nested] 16+ messages in thread