public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janne Blomqvist <blomqvist.janne@gmail.com>
To: Steve Kargl <sgk@troutmask.apl.washington.edu>
Cc: Fortran List <fortran@gcc.gnu.org>,
	GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fortran -- clean up KILL
Date: Mon, 12 Mar 2018 19:05:00 -0000	[thread overview]
Message-ID: <CAO9iq9HBO2z+1YGQw5yCVYBS=UoBM9qSYC--DoAEW8um1hixyQ@mail.gmail.com> (raw)
In-Reply-To: <20180312173706.GB61632@troutmask.apl.washington.edu>

On Mon, Mar 12, 2018 at 7:37 PM, Steve Kargl
<sgk@troutmask.apl.washington.edu> 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

  reply	other threads:[~2018-03-12 19:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-11 16:52 Steve Kargl
2018-03-11 20:16 ` Janne Blomqvist
2018-03-11 20:42   ` Steve Kargl
2018-03-12 16:56     ` Janne Blomqvist
2018-03-12 17:37       ` Steve Kargl
2018-03-12 19:05         ` Janne Blomqvist [this message]
2018-03-13  4:08           ` Steve Kargl
2018-03-13 19:49             ` Janne Blomqvist
2018-03-14  0:57               ` Steve Kargl
2018-03-15 10:18                 ` Bin.Cheng
2018-03-15 12:11                   ` Bin.Cheng
2018-03-15 12:20                     ` Bin.Cheng
2018-03-15 15:07                       ` Steve Kargl
2018-03-15 12:35                     ` Richard Biener
2018-03-15 14:10                       ` Steve Kargl
2018-03-15 16:35                         ` Jakub Jelinek
2018-03-15 15:45                           ` Bin.Cheng
2018-03-15 17:35                             ` Jakub Jelinek
2018-03-15 15:57                               ` Bin.Cheng
2018-03-15 16:28                           ` Steve Kargl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAO9iq9HBO2z+1YGQw5yCVYBS=UoBM9qSYC--DoAEW8um1hixyQ@mail.gmail.com' \
    --to=blomqvist.janne@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=sgk@troutmask.apl.washington.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).