Re: [PATCH] Fortran -- clean up KILL

[Steve Kargl <sgk@troutmask.apl.washington.edu>]

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_. 

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.  

-- 
Steve