Re: [PATCH] Fortran -- clean up KILL

[Janne Blomqvist <blomqvist.janne@gmail.com>]

On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote:
>> On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl
>> <sgk@troutmask.apl.washington.edu> wrote:
>> > The attach patch cleans up KILL to match its
>> > documentation.  In doing so, I have changed
>> > the argument keywords to consistently use
>> > pid and sig.  If no one objects, I intend to
>> > commit this tomorrow.
>> >
>> > 2018-03-11  Steven G. Kargl  <kargls@gcc.gnu.org>
>> >
>> >         * check.c (gfc_check_kill):  Check pid and sig are scalar.
>> >         (gfc_check_kill_sub): Restrict kind to 4 and 8.
>> >         * intrinsic.c (add_function): Sort keyword list.  Add pid and sig
>> >         keywords for KILL.  Remove redundant *back="back" in favor of the
>> >         original *bck="back".
>> >         (add_subroutines): Sort keyword list.  Add pid and sig keywords
>> >         for KILL.
>> >         * intrinsic.texi: Fix documentation to consistently use pid and sig.
>> >         * iresolve.c (gfc_resolve_kill): Kind can only be 4 or 8.  Choose the
>> >         correct function.
>> >         (gfc_resolve_rename_sub): Add comment.
>>
>> The patch per se looks fine, but while you're at it, it would be nice
>> to get rid of all but one of the libgfortran entry points and do the
>> typecasting etc. in the frontend instead..
>>
>
> Thanks.  Note, the documentation specifically states that
> only INTEGER(4) and INTEGER(8) are supported, so there is
> only 2 entry points for the function and 4(?) for the
> subroutine version.  nm shows
>
> 00000000 T _gfortran_kill_i4
> 00000000 T _gfortran_kill_i4_sub
> 00000000 T _gfortran_kill_i8
> 00000000 T _gfortran_kill_i8_sub
> 00000000 T _gfortrani_kill_i4_sub
> 00000000 T _gfortrani_kill_i8_sub
>
> I don't recall what the difference is between _gfortran_
> and _gfortrani_.

IIRC, the "i" stands for internal, it's symbols called internally in
gfortran and are not externally visible in the .so (though you can
still see them in the .a). So we have 4 external symbols that are part
of the libgfortran API.

> I suppose we could remove the restriction to INTEGER(4) and
> INTEGER(8), but I don't see any reason to do so.  INTEGER(1)
> is too limited given that at least on FreeBSD the lower pid's
> correspond to system processes.  Using 'ps ax' suggests that
> the first 1000 or so processes are from system start up.
> INTEGER(16) (if supported) seems to be overkill in that I
> doubt any OS uses a 64-bit pid_t.

I'm not sure there's any particular reason for the kind=4,8
restriction except that "it's the same restriction g77 had". And AFAIK
there are no systems with a 64-bit pid_t, so a plain int should be
enough. So it should suffice to have a single libgfortran function,
say with the prototype

int _gfortran_kill (int pid, int sig);

and the frontend would take care of whatever massaging to handle
whether it's called as a function or subroutine, and whatever
typecasting is necessary. Whether we want to limit it to kind=4,8 or
allow arbitrary kinds I don't have any particularly strong opinion on.



-- 
Janne Blomqvist