https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29651
--- Comment #16 from Harald Anlauf <anlauf at gmx dot de> --- (In reply to Janne Blomqvist from comment #13) > 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..? Maybe. I was wondering whether the documented behavior https://gcc.gnu.org/onlinedocs/gfortran/SIGNAL.html#SIGNAL needs to be adapted to support both 32- and 64-bit platforms, given that HANDLER makes most sense if it is either a procedure or an integer(c_intptr_t) - I hope I got that right - and status (if present) should be integer(c_intptr_t), so that a saved signal handler could be restored later. I'd expect fun with 32-/64-bits, endianness, target and host dependence.
