This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fortran -- clean up KILL
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