egcs-19990502 u77-test.f failure on Irix6.5 -Reply

[Tim C Prince]

A certain number of legacy codes are using etime and maybe
dtime, particularly as f95 is not yet generally available in Unix.  I
don't know why anyone having f90 or g77 available would be
using ctime, but I thought it was there only for legacy
compatibility.  If anyone is writing or modifying code, they
should be using DATE_AND_TIME.  My main interest here is in
being able to show a clean testsuite for g77; either these things
should work or be deprecated or removed.  That's prompt work!

>>> craig@jcb-sc.com 05/03/99 05:09pm >>>
>Small test case:
>
>      implicit none
>      intrinsic time, ctime
>      integer i
>      character ctim*25, ctim2*25
>
>      i = time ()
>      ctim = ctime (i)
>      call ctime (ctim2, i)
>
>      print *, 'CTIME()    = ', ctim
>      print *, 'CALL CTIME = ', ctim2
>      if (ctim .ne. ctim2) then
>         print *, 'CTIME() disagrees with CALL CTIME'
>      end if
>
>      end
>
>
Ah.  But.  I see the problem.  g77 is passing a `long *' for xstime,
even though it really points to an `int', not a `long'.  Naughty.  I
was wondering why there was an apparently spurious "st
%l1,[%fp-116]"
before the second call, why earlier there was a "std" into what
seemed to be the location for `i', etc.  Looking at the Irix6 output
Tim sent confirmed this.

Also, I'm reversing the arguments for CTIME_subr, DTIME_subr,
ETIME_subr,
and TTYNAM_subr, to be consistent with the other _subr's I
invented.
Hope this doesn't inconvenience anybody -- if there's any legacy
code
out there that expects the previous calling sequence, I'll be very
surprised, and would be willing to support the old ones as well
(as I
believe they're all distinguishable by g77 versus the new ones).

        tq vm, (burley)