[Bug fortran/106579] ieee_signaling_nan problem in fortran on powerpc64

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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.