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.
