powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules

powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules

[Jakub Jelinek]

Hi!

Apparently something we (at least I) have totally missed, we clearly have a
problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
We have:
    __ieee_arithmetic_MOD_ieee_class_16;
    __ieee_arithmetic_MOD_ieee_support_datatype_16;
    __ieee_arithmetic_MOD_ieee_support_denormal_16;
    __ieee_arithmetic_MOD_ieee_support_divide_16;
    __ieee_arithmetic_MOD_ieee_support_inf_16;
    __ieee_arithmetic_MOD_ieee_support_io_16;
    __ieee_arithmetic_MOD_ieee_support_nan_16;
    __ieee_arithmetic_MOD_ieee_support_rounding_16;
    __ieee_arithmetic_MOD_ieee_support_sqrt_16;
    __ieee_arithmetic_MOD_ieee_support_standard_16;
    __ieee_arithmetic_MOD_ieee_support_underflow_control_16;
    __ieee_arithmetic_MOD_ieee_value_16;
    __ieee_exceptions_MOD_ieee_support_flag_16;
  __ieee_arithmetic_MOD_ieee_support_subnormal_16;
exported from the library, but no corresponding _17 entrypoints.
1) is there any way how to define them in a different source file
   so that they can be compiled with -mabi=ieeelongdouble?
2) I'm afraid interfaces like:
  interface IEEE_IS_NEGATIVE
    procedure &
#ifdef HAVE_GFC_REAL_16
      _gfortran_ieee_is_negative_16, &
#endif
#ifdef HAVE_GFC_REAL_10
      _gfortran_ieee_is_negative_10, &
#endif
      _gfortran_ieee_is_negative_8, _gfortran_ieee_is_negative_4
  end interface
  public :: IEEE_IS_NEGATIVE
  just aren't going to work for the real(kind=16) case
  when it has abi_kind 17, the FE will still resolve it to the
  _16 case or error out that we have two real(kind=16) entries.
Can everything these modules do be resolved at compile time inline
such that for the abi_kind 17 nothing is really called, or
any other thoughts on this?

	Jakub

Re: powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules

[Tobias Burnus]

Hi,

On 25.01.22 12:44, Jakub Jelinek via Fortran wrote:
> Apparently something we (at least I) have totally missed, we clearly have a
> problem with the IEEE modules for the dual -mabi={ibm,ieee}longdouble.
> We have:
>      __ieee_arithmetic_MOD_ieee_class_16;
>      __ieee_arithmetic_MOD_ieee_support_datatype_16;
... exported from the library, but no corresponding _17 entrypoints.
> Can everything these modules do be resolved at compile time inline
> such that for the abi_kind 17 nothing is really called, or
> any other thoughts on this?

We already have in gfc_conv_function_expr:

   /* The IEEE_ARITHMETIC functions are caught here. */
   if (sym->from_intmod == INTMOD_IEEE_ARITHMETIC)
     if (gfc_conv_ieee_arithmetic_function (se, expr))
       return;

which handles:
   if (startswith (name, "_gfortran_ieee_is_nan"))
   else if (startswith (name, "_gfortran_ieee_is_finite"))
   else if (startswith (name, "_gfortran_ieee_unordered"))
   else if (startswith (name, "_gfortran_ieee_is_normal"))
   else if (startswith (name, "_gfortran_ieee_is_negative"))
   else if (startswith (name, "_gfortran_ieee_copy_sign"))
   else if (startswith (name, "_gfortran_ieee_scalb"))
   else if (startswith (name, "_gfortran_ieee_next_after"))
   else if (startswith (name, "_gfortran_ieee_rem"))
   else if (startswith (name, "_gfortran_ieee_logb"))
   else if (startswith (name, "_gfortran_ieee_rint"))
else -> 'return false;' -> library call.

Thus, more functions could be handled in the compiler itself.
(Likewise for INTMOD_IEEE_EXCEPTIONS, not that I know whether
that has any relevant functions.)

Alternatively, kind= tweaking could be done here as well.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: powerpc64le real(kind=16) and IEEE_{ARITHMETIC,EXCEPTIONS} modules

[FX]

> Thus, more functions could be handled in the compiler itself.
> (Likewise for INTMOD_IEEE_EXCEPTIONS, not that I know whether
> that has any relevant functions.)

In theory, there is no reason why we need an explicit .mod file in the library for any of the three IEEE modules. They would probably be better treated as compiler intrinsics in the front-end itself, in fact, like all other intrinsics. It would also be easier to adjust for generic forms, and provide better diagnostics for mismatching arguments, etc. This seems to be the way to go, as the next standard versions have added even more intrinsics, some of which really shouldn’t be function calls (comparison, ordering, etc).

The reason those modules are not fully implemented in the front-end is simple: I didn’t know how to implement them directly in the front-end, and I am not entirely sure we have the appropriate stuff for that. ISO_FORTRAN_ENV is implemented in the front-end, but its members are simpler, really.

In a way, you can see this as a call for help: if someone front-end-savvy has ideas how to do this, we could partner up ;)

FX