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

craig@jcb-sc.com craig@jcb-sc.com
Mon May 3 15:13:00 GMT 1999


>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
>
>and an assembly dump (-O2):
>
>MAIN__:
>        !#PROLOGUE# 0
>        save %sp,-216,%sp
>        !#PROLOGUE# 1
>        call G77_time_0,0
>        nop
>        mov %o0,%l0
>        mov %o1,%l1
>        mov %l1,%o3
>        sra %l1,31,%o2
>        add %fp,-104,%l2
>        std %o2,[%fp-112]
>        add %fp,-48,%l3
>        mov %l2,%o0
>        mov 24,%o1
>        call G77_ctime_0,0
>        add %fp,-112,%o2
>        mov %l2,%o1
>        mov %l3,%o0
>        mov 25,%o2
>        call s_copy,0
>        mov 24,%o3
>        add %fp,-80,%l2
>        st %l1,[%fp-116]
>        mov %l2,%o0
>        mov 25,%o1
>        call G77_ctime_0,0
>
>I am not a Sparc assembly expert, but the pointer arithmetic looks
>very suspicious to me.  If it does what I think it does, we are
>handing G77_ctime_0 zero for its `xstime' parameter when invoked as a
>subroutine.

Well, you cut off the delay slot after the last call.  My guess is that
it looks like this:

>        add %fp,-112,%o2

In which case, the right thing *is* being passed.

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)


More information about the Gcc-bugs mailing list