This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fortran -- clean up KILL


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]