[Bug fortran/106975] New: RFC – add: '!$GCC ATTRIBUTE promote_kind ::' (convert_kind) for integer/logical dummy attributes, cf. '!DIR$ IGNORE_TKR(k)'

[Bug fortran/106975] New: RFC – add: '!$GCC ATTRIBUTE promote_kind ::' (convert_kind) for integer/logical dummy attributes, cf. '!DIR$ IGNORE_TKR(k)'

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106975

            Bug ID: 106975
           Summary: RFC – add: '!$GCC ATTRIBUTE promote_kind ::'
                    (convert_kind) for integer/logical dummy attributes,
                    cf. '!DIR$ IGNORE_TKR(k)'
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: openacc, openmp
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org
  Target Milestone: ---

When writing interfaces to library functions, the number of interfaces required
to implement increases because the TKI rule requires that the kind of the
actual argument and the actual argument must be the same.

If the defined API supports, e.g.,

          subroutine omp_set_dynamic (dynamic_threads)
            logical, intent (in) :: dynamic_threads
          end subroutine omp_set_dynamic

and with -fdefault-integer-8 this implies that both kind=4 and kind=8 have to
be
supported. (For instance, by two specific functions under the same generic
name).

Similar issues exist for

  type(c_ptr) omp_target_alloc(size, device_num)

where 'size' should support all sizes, i.e. up to huge(0_c_size_t) but it might
be
much more convenient to pass a default-kind integer in most cases. If the
implementation
now supports all those, it means:
  kind=4 for size, device_num  (-m32)
  kind=8 for size, device_num  (-m64 -fdefault-integer-8)
  kind=4 for size, kind=8 for device_num (-m32 -fdefault-integer-8)
  kind=8 for size, kind=4 for device_num (-m64)

Albeit only supporting default integer or always forcing c_size_t for size
might be
possible. The API upstream interfaces might settle for a subset which might
then change
when realizing that the default-kind "integer" might not be sufficient for
size...



Other compilers permit:
 !DIR$ IGNORE_TKR(k) <argument>
to ignore the K of TKR (or more). I assume/hope this implies kind promotion and
not
just ignoring the kind – otherwise it seems to be rather pointless to me,
contrary to
full 'tkr' (only a pointer is needed).

In any case, I think it makes sense to have something like:
  !$GCC ATTRIBUTE promote_kind ::
but restricting it to:
  * only integer and logical
  * only scalars
  * possibly only to VALUE, but in principle also intent(in/out/inout) are also
fine.
+ conversion warnings following the existing ones for assignments.

I used 'promote_kind' but other names like 'convert_kind' would be equally good
(bike-shading!)

And I think for real/complex the accidental precision loss is great (e.g. for
decimal 0.1 represented as binary) and the demand is too low to support it for
real/complex as well.
Likewise, I do not see a real point in doing this promotion for arrays albeit
it would be possible similar to the copy-in/out for arrays. (And with the same
restrictions + implications on pointer association.)

See also https://gcc.gnu.org/onlinedocs/gfortran/ATTRIBUTES-directive.html for
the existing attributes, in particular ATTRIBUTES which supports NO_ARG_CHECK
(and DEPRECATED).

 * * *

I marked it as OpenMP/OpenACC topic as the -fdefault-integer-8 issue occurs a
lot (→ libgomp/{openacc.f90,openacc_lib.h,omp_lib.{h,f90}.in} ) and there might
be more issues coming up. (Not publicly visible: Cf. OpenMP spec's omp_target_*
in Fortran disscussion in issue 3348.)