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

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

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

Janne Blomqvist <jb at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jb at gcc dot gnu.org

--- Comment #13 from Janne Blomqvist <jb at gcc dot gnu.org> ---
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..?