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

[craig@jcb-sc.com]

>Aargh.  I forgot about the delay slots.  It is different:
>
>        add %fp,-116,%o2
>
>>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.
>
>Does your analysis change knowing what was in the delay slot?

A bit.  I just can't see how the call ends up different, pertaining
to the third argument, between the function and subroutine versions,
by looking at the relevant code in com.c.  But it is the sort of code
that can hide bugs "in plain view", as I've learned from experience!

The function version seems to work okay, while the subroutine
version...yet I notice there seems to be no stack slot for `i', and
the registers for it got trashed (well, converted to 32 bits), so
perhaps this is due to a back-end bug.

Could y'all retry your test case, changed to look as follows?

      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
      print *, 'I is ', i

      end

The addition of the print statement at the end should ensure that
the back end keeps `i' around somewhere.  Then, the question is,
does it properly handle passing the `&((long int *) i)', that is,
the address of the conversion of `i' to `long int', to G77_ctime_0
both times.  And, if not, why not -- is the g77 front end doing
something wrong, or is it the back end?

Also, try the above test case as is, and then with the two lines calling
ctime swapped (i.e. the subroutine call *before* the function call).
That might expose where the problem is.

In both cases, let me know how the program behaves *and* include .s
output (for sparc and Irix6 and, heck, a powerpc system failing u77-test.f
while anyone's at it), as y'all have been doing so far.  That makes
it really easy for me.  (Even though I don't have any docs on Irix6
assembly code, it's easy enough to infer what's going on.)

        tq vm, (burley)