https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
CC| |kargl at gcc dot gnu.org
--- Comment #14 from kargl at gcc dot gnu.org ---
(In reply to Janne Blomqvist from comment #13)
> From https://gcc.gnu.org/wiki/LibgfortranAbiCleanup :
>
>> For many intrinsics there are multiple implementations for different
>> argument kinds. In many cases these should be replaced by a single
>> implementation and having the frontend convert the arguments. E.g.
>> fseek, isatty etc. Of course intrinsics with floating point arguments
>> or that are otherwise performance sensitive must still be kept separate.
>> Also, it should be noted that the current system with foo_i4 and
>> foo_i8 works for F95 where intrinsics require an integer of default
>> kind, in F2003 this restricitons has been lifted and most intrinsics
>> should now accept integers of any kind the compiler supports. Hence
>> doing intrinsics the old way with separate library functions leads
>> to a combinatorial explosion for those intrinsics with multiple
>> integer arguments.
>
>
> Now, for the G77 intrinsics, we don't need to follow the standard and can do
> whatever we want. Though I think the general approach above is good for G77
> intrinsics too, namely have one implementation in the library that uses a
> suitable integer type for whatever the intrinsic is doing, then have the
> frontend generate temporary variables or whatever if the intrinsic is called
> with some other kind. For the particular case of signal, I wonder if it
> wouldn't in the end be as easy to just generate a call to libc signal()
> directly in the frontend..?
This PR is related PR fortran/30372. We basically need to audit all G77
intrinsic routines. KILL is definitely broken, and I have patch for it.
Currently, for this
integer(1) :: stat1, pid1, sig1
integer(2) :: stat2, pid2, sig2
integer(4) :: stat4, pid4, sig4
integer :: stat, pid, sig
integer(8) :: stat8, pid8, sig8
stat1 = kill(pid1, sig1)
stat2 = kill(pid2, sig2)
stat4 = kill(pid4, sig4)
stat8 = kill(pid8, sig8)
stat = kill(pid, sig)
gfortran gives
stat1 = (integer(kind=1)) _gfortran_kill_i4 (&pid1, &sig1);
stat2 = (integer(kind=2)) _gfortran_kill_i4 (&pid2, &sig2);
stat4 = _gfortran_kill_i4 (&pid4, &sig4);
stat8 = (integer(kind=8)) _gfortran_kill_i4 (&pid8, &sig8);
stat = _gfortran_kill_i4 (&pid, &sig);
Lines 1, 2, and 4 are definitely wrong. My patch does
{
integer(kind=4) D.3682;
integer(kind=4) D.3683;
D.3682 = (integer(kind=4)) pid1;
D.3683 = (integer(kind=4)) sig1;
stat1 = (integer(kind=1)) _gfortran_kill_i4 (&D.3682, &D.3683);
}
{
integer(kind=4) D.3685;
integer(kind=4) D.3686;
D.3685 = (integer(kind=4)) pid2;
D.3686 = (integer(kind=4)) sig2;
stat2 = (integer(kind=2)) _gfortran_kill_i4 (&D.3685, &D.3686);
}
stat4 = _gfortran_kill_i4 (&pid4, &sig4);
stat8 = _gfortran_kill_i8 (&pid8, &sig8);
stat = _gfortran_kill_i4 (&pid, &sig);
Lines 1 and 2 have converted the type specs of pid1,2 and sig1,2
to the current type. Line 4 now calls the correct routine.
Things even more broke with argument keyword use. The documentation
has KILL(C,VALUE) except the keyword that gfortran recognizes is
COUNT. I've actaully changed the keywords to PID and SIG, which
makes for sense (and yes, probably breaks backward compatibility to
g77 except no one has reported a problems with keywords).
