From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98901 invoked by alias); 12 Mar 2018 17:37:10 -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 98876 invoked by uid 89); 12 Mar 2018 17:37:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 spammy=life's, lifes, Hx-languages-length:1721, life X-Spam-User: qpsmtpd, 2 recipients X-HELO: troutmask.apl.washington.edu Received: from troutmask.apl.washington.edu (HELO troutmask.apl.washington.edu) (128.95.76.21) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 17:37:08 +0000 Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.15.2/8.15.2) with ESMTPS id w2CHb77v062043 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 12 Mar 2018 10:37:07 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.15.2/8.15.2/Submit) id w2CHb68w062042; Mon, 12 Mar 2018 10:37:06 -0700 (PDT) (envelope-from sgk) Date: Mon, 12 Mar 2018 17:37:00 -0000 From: Steve Kargl To: Janne Blomqvist Cc: Fortran List , GCC Patches Subject: Re: [PATCH] Fortran -- clean up KILL Message-ID: <20180312173706.GB61632@troutmask.apl.washington.edu> Reply-To: sgk@troutmask.apl.washington.edu References: <20180311165209.GA60279@troutmask.apl.washington.edu> <20180311204239.GA56613@troutmask.apl.washington.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2018-03/txt/msg00046.txt.bz2 On Mon, Mar 12, 2018 at 06:56:24PM +0200, Janne Blomqvist wrote: > On Sun, Mar 11, 2018 at 10:42 PM, Steve Kargl > > 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. > Keeping kind=4,8 simply makes life easier for people who use -fdefault-integer-8. It also makes our life's easier. Where do you want the conversion to occur? We don't have a conv_intrinsic_kill in trans-intrinsic.c. The return type is documented to be that of pid, so we need to convert pid and sig to int and then convert the presumably returned int to type of pid. BTW, I'm not too familiar with all the nuances of symbol versioning, but I thought we needed to drag the 6 exported library symbols along forever. -- Steve