This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: small libf2c cleanups
- To: egcs at cygnus dot com
- Subject: Re: small libf2c cleanups
- From: Craig Burley <burley at gnu dot org>
- Date: Sat, 18 Oct 1997 14:25:54 -0400 (EDT)
>I would be delighted if it's changed, but last I heard, g77 didn't
>properly support integer*8. So even if we declared the function
>properly, you couldn't assign the value to anything without loosing
>information.
Yes, it does, and if SIGNAL is supposed to return a pointer,
then g77 can handle that.
However, I can't figure out what SIGNAL is supposed to do in the
Fortran libU77 world (which I know little about, aside from what
I've learned by doing g77). Presumably it is just a wrapper for
signal(2), in which case it looks like SIGNAL should return a pointer
as well.
It looks like the documentation for SIGNAL is botched a bit, at least,
in that it confuses the NUMBER and HANDLER arguments in the sentence
"If NUMBER is an integer...". Can anyone confirm this?
Anyway, to teach g77 that an intrinsic returns a pointer as a
function value, change gcc/f/com-rt.def so its entry starts with
"Ip:", a la LOC. However, I just noticed that fixing the subroutine
form of SIGNAL is non-trivial, since I didn't bother making "Ip" work
as an argument, probably because I was thinking only of LOC when
I implemented it. Sigh.
Since I'm still muchly in flux in terms of my current systems, I can't
do much about this just yet, but maybe early this coming week I'll
be able to send patches for some of these things.
BTW, I've known SIGNAL probably didn't work right on Alphas for some
time, which is why gcc/f/BUGS contains an entry about it. Thanks
for working on it!!
tq vm, (burley)