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