On Sun, Mar 11, 2018 at 10:16:01PM +0200, Janne Blomqvist wrote: > On Sun, Mar 11, 2018 at 6:52 PM, Steve Kargl > <s...@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 <kar...@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