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

Reply via email to