From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91666 invoked by alias); 12 Mar 2018 19:05:13 -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 91646 invoked by uid 89); 12 Mar 2018 19:05:12 -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=life X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-yw0-f179.google.com Received: from mail-yw0-f179.google.com (HELO mail-yw0-f179.google.com) (209.85.161.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 12 Mar 2018 19:05:11 +0000 Received: by mail-yw0-f179.google.com with SMTP id y203so1292174ywg.5; Mon, 12 Mar 2018 12:05:11 -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=uHKhaNhXp2OLbuI8QFsn/qYAR8sVv+eS6MbcAwW4BwQ=; b=G9xruMjIzU4xkA12fkPl7p3aQ0SeNgFGAUyJyitbi3B9Kq9Lz+3rqMeWQRh1JwNtU0 Vr7P8KbeANKWInluf72JbuXKFjJsGSD7GFNjRdgFIseIGgstBE9j6gytEpYlVvmbu3MV 6HxQyFvCDvOFb1eby/YL2iwGq+aeOou4ECH3dnwCgXilBIh8iJVS9dvhSqQD7VwI1mbu qMkZ+b+avGV2GawzSIebrWGEslUF7JlBNGtwe20IgdX4IyFugxhg2k54cl/U4+RoUT7r IaBeGYBI2wSOOTmZeZc9KLlgudXHc0MdHnpkU9lcHNdQ/7deqqq8GwGW46WRSKCSGyhb 3lNg== X-Gm-Message-State: AElRT7GnwxrD8EBHoPU0vfF5upyiiMvoDyjTsuBmdn2+njesl9Qakef3 d5UsbyygyRjLqDAXwtJmmiJ+mzNdRHbf2d6uuE0= X-Google-Smtp-Source: AG47ELvBRIYvFXKeDFv5wWbF/wvQVDnhrQIj0d0yrPa3qIz4+qzn7sM3sjf/ELsHEOIYQHr870pAqRbMP5y+XFs2QSg= X-Received: by 2002:a25:dbcb:: with SMTP id g194-v6mr4803894ybf.511.1520881509749; Mon, 12 Mar 2018 12:05:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.230.151 with HTTP; Mon, 12 Mar 2018 12:05:09 -0700 (PDT) In-Reply-To: <20180312173706.GB61632@troutmask.apl.washington.edu> References: <20180311165209.GA60279@troutmask.apl.washington.edu> <20180311204239.GA56613@troutmask.apl.washington.edu> <20180312173706.GB61632@troutmask.apl.washington.edu> From: Janne Blomqvist Date: Mon, 12 Mar 2018 19:05: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/msg00047.txt.bz2 On Mon, Mar 12, 2018 at 7:37 PM, Steve Kargl wrote: > 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. Yes, I understand that -fdefault-integer-8 (or whatever the equivalent option was called on g77) is the original motivation. Like I said, I don't have any particular opinion on whether we should keep that restriction or not. On one hand, more recent versions of the standard has lifted restrictions that integer intrinsic arguments have to be of default kind in many cases, OTOH KILL is not a standard intrinsic but something inherited from g77. So, meh. > 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. No, when we bump the major .so version number, as we have already done for GCC 8, the clock resets and we can remove unnecessary stuff. The symbol versioning stuff is only useful as long as we keep the same major .so version number. -- Janne Blomqvist