[Bug fortran/29651] Subroutine: Kind convertion of intent(out) value: signal

[anlauf at gmx dot de]

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

--- Comment #12 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Jerry DeLisle from comment #9)
> An easy fix to this would be to disallow kind=2 integer as an argument
> during checking.

Since SIGNAL is a GNU extension, we are at liberty what to allow.

What is definitely needed is a kind=8 version of status for 64-bit
platforms.  From the manpage signal(2):

SYNOPSIS
       #include <signal.h>

       typedef void (*sighandler_t)(int);

       sighandler_t signal(int signum, sighandler_t handler);

A modified version of the code in comment#1,

implicit none
  integer :: i1,i2
  integer(4) :: status4, proc4
  integer(8) :: status8, proc8
  i1 = 0; i2 = 0
  call signal(i1, proc4, status4)
  print *,status4
  call signal(i2, proc8, status8)
  print *,status8
end

produces the dump excerpt:

    integer(kind=4) D.3682;
    integer(kind=4) D.3683;

    D.3682 = (integer(kind=4)) proc8;
    D.3683 = (integer(kind=4)) status8;
    _gfortran_signal_sub_int (&i2, &D.3682, &D.3683);

If one wants to save the old signal handler, proc and status of type
integer(c_intptr_t) need to be supported.  One may even require that
they have the same kind value, as different values do not make much sense.

Looking at libgfortran/intrinsics/signal.c, I think the appropriate
support from the library side is trivial.  However, I think that the
argument status from the existing functions signal_sub and signal_sub_int
need to be changed from int* to GFC_INTEGER_4* for the existing version,
and GFC_INTEGER_8* for the other version to be added.

If there is consensus on such restrictions, I could try to work on a
trivial patch for supporting the above.