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

["kargl at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Janne Blomqvist from comment #13)
> From https://gcc.gnu.org/wiki/LibgfortranAbiCleanup :
> 
>> For many intrinsics there are multiple implementations for different
>> argument kinds. In many cases these should be replaced by a single
>> implementation and having the frontend convert the arguments. E.g.
>> fseek, isatty etc. Of course intrinsics with floating point arguments
>> or that are otherwise performance sensitive must still be kept separate.
>> Also, it should be noted that the current system with foo_i4 and
>> foo_i8 works for F95 where intrinsics require an integer of default
>> kind, in F2003 this restricitons has been lifted and most intrinsics
>> should now accept integers of any kind the compiler supports. Hence
>> doing intrinsics the old way with separate library functions leads
>> to a combinatorial explosion for those intrinsics with multiple
>> integer arguments. 
> 
> 
> Now, for the G77 intrinsics, we don't need to follow the standard and can do
> whatever we want. Though I think the general approach above is good for G77
> intrinsics too, namely have one implementation in the library that uses a
> suitable integer type for whatever the intrinsic is doing, then have the
> frontend generate temporary variables or whatever if the intrinsic is called
> with some other kind. For the particular case of signal, I wonder if it
> wouldn't in the end be as easy to just generate a call to libc signal()
> directly in the frontend..?

This PR is related PR fortran/30372. We basically need to audit all G77
intrinsic routines.  KILL is definitely broken, and I have patch for it.
Currently, for this

   integer(1) :: stat1, pid1, sig1
   integer(2) :: stat2, pid2, sig2
   integer(4) :: stat4, pid4, sig4
   integer    :: stat,  pid,  sig
   integer(8) :: stat8, pid8, sig8

   stat1 = kill(pid1, sig1)
   stat2 = kill(pid2, sig2)
   stat4 = kill(pid4, sig4)
   stat8 = kill(pid8, sig8)
   stat  = kill(pid,  sig)

gfortran gives

  stat1 = (integer(kind=1)) _gfortran_kill_i4 (&pid1, &sig1);
  stat2 = (integer(kind=2)) _gfortran_kill_i4 (&pid2, &sig2);
  stat4 = _gfortran_kill_i4 (&pid4, &sig4);
  stat8 = (integer(kind=8)) _gfortran_kill_i4 (&pid8, &sig8);
  stat = _gfortran_kill_i4 (&pid, &sig);

Lines 1, 2, and 4 are definitely wrong.  My patch does

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

    D.3682 = (integer(kind=4)) pid1;
    D.3683 = (integer(kind=4)) sig1;
    stat1 = (integer(kind=1)) _gfortran_kill_i4 (&D.3682, &D.3683);
  }
  {
    integer(kind=4) D.3685;
    integer(kind=4) D.3686;

    D.3685 = (integer(kind=4)) pid2;
    D.3686 = (integer(kind=4)) sig2;
    stat2 = (integer(kind=2)) _gfortran_kill_i4 (&D.3685, &D.3686);
  }
  stat4 = _gfortran_kill_i4 (&pid4, &sig4);
  stat8 = _gfortran_kill_i8 (&pid8, &sig8);
  stat = _gfortran_kill_i4 (&pid, &sig);

Lines 1 and 2 have converted the type specs of pid1,2 and sig1,2
to the current type.  Line 4 now calls the correct routine.

Things even more broke with argument keyword use.  The documentation
has KILL(C,VALUE) except the keyword that gfortran recognizes is
COUNT.  I've actaully changed the keywords to PID and SIG, which
makes for sense (and yes, probably breaks backward compatibility to
g77 except no one has reported a problems with keywords).