From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 110826 invoked by alias); 12 Mar 2018 16:56:28 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 110804 invoked by uid 89); 12 Mar 2018 16:56:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yw0-f182.google.com Received: from mail-yw0-f182.google.com (HELO mail-yw0-f182.google.com) (209.85.161.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 16:56:26 +0000 Received: by mail-yw0-f182.google.com with SMTP id w12so5877937ywa.8; Mon, 12 Mar 2018 09:56:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wQjdj+rmrnkiBvow378cGPci+4jFe/q7eCFQw2xTD6o=; b=S0HjuIrtrbep0a8dLHp85fxGw3TwH7zmitAbQIOOT89TtO3TUKJznqvuFiRUk0lAgc Jbjfweu3yHsjLGFO/WY9AFJXxbV/Bk6mONubkQf7ZbyRcugbcBWc02EeBpA9Qs0ThiZX 4Q5fb5iwmNOUKtNkcgopdjmpe8dAHBy3qUpipmwGy5tY3YxngbWQnW1fbJWV5QX3VCVV OsyoXWD4TclcMvkLTM8RfB8pfdtXSU3e9kBbiWZ45/vE7hh5LivoQJ/vP0lMBWE8uqWy U3O13XBOBQXhR3OmxPWbR4m3iBfsNxmn//Jv/XfPMwYFY9i8kypj0VsvsBmRAQ1mmsuh LNdQ== X-Gm-Message-State: AElRT7HJeEdknzXs/OwIkH2uYGKMisSB7jTxXijCMoPAzLCSeWN652Sh +ZVMETx8BOz1qB7XCuRmCuYsEWOgVSCxRkUjAk0= X-Google-Smtp-Source: AG47ELsgrkDlGt8IzcPHk1tjdPEOtWykAfdkYiBcBCGpZ3PijZXAyqqUWXm9iOKTqkr4myZ0imLe67cK0iEBa6lkkhk= X-Received: by 10.129.174.4 with SMTP id m4mr5172967ywh.412.1520873784793; Mon, 12 Mar 2018 09:56:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.151 with HTTP; Mon, 12 Mar 2018 09:56:24 -0700 (PDT) In-Reply-To: <20180311204239.GA56613@troutmask.apl.washington.edu> References: <20180311165209.GA60279@troutmask.apl.washington.edu> <20180311204239.GA56613@troutmask.apl.washington.edu> From: Janne Blomqvist Date: Mon, 12 Mar 2018 16:56:00 -0000 Message-ID: Subject: Re: [PATCH] Fortran -- clean up KILL To: Steve Kargl Cc: Fortran List , GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00044.txt.bz2 On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl 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 >> 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 >> > >> > * 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