Xref: utzoo comp.unix.ultrix:1871 comp.sys.mips:186
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!apple!mips!lilian
From: lilian@mips.COM (Lilian Leung)
Newsgroups: comp.unix.ultrix,comp.sys.mips
Subject: Re: f77 bug on decstation 3100
Message-ID: <28829@gumby.mips.COM>
Date: 5 Oct 89 18:27:31 GMT
References: <wZ_Gp_u00YU5AAxIlC@andrew.cmu.edu>
Reply-To: lilian@mips.COM (Lilian Leung)
Organization: MIPS Computer Systems, Sunnyvale, CA
Lines: 81

In article <wZ_Gp_u00YU5AAxIlC@andrew.cmu.edu> mikem+@andrew.cmu.edu (Michael Meyer) writes:
>I'm not sure if this is a generic Mips compiler bug, or specific to the
>decstation.  I've submitted a problem report to Digital.
>
>I believe that the following function is valid Fortran 77.  
>	program
>	complex x,y
>	complex fred
>	x = (1.0,1.0)
>	y = (2.0,1.0)
>	write(*,*) fred(x,y)
>	stop
>	end
>	complex function fred(x,y)
>	complex x,y
>	fred=(10,10)
>	fred= x*conjg(y) + fred
>	return
>	end
>
>However on a decstation 3100, the line 
>fred= x*conjg(y) + fred  
>has the effect of just
>fred= x*conjg(y)
>That is the output from this program is (5,0) rather than (15,10).
>It appears that the compiler ignores "fred" on the left hand side of the
>assignment statement. Perhaps it is even trying to do a recursive call? 
>I'm not sure if this behaviour happens only for complex functions, that
>is just the case where I ran into problems.
>
>The Fortran standard,
>ANSI X3.9-1978 15.5.3 states
>
>  Within a function subprogram, the symbolic name of a 
>  function specified by a FUNCTION or ENTRY statement must not
>  appear in any other nonexecutable statement, except a type-
>  statement.  In an executable statement, such a name may
>  appear only as a variable.
>
>while section 15.5.1 of the Fortran 77 Ansi Standard:
>
>  During every execution of the external function
>  this variable [they are referring to the function name]
>  must become defined and, once defined, may be referenced
>  or become redefined.
>
>Here is the result of running this program on a decstation 3100, Ultrix
>3.1, UWS 2.1.
>temper> f77 -O0 -v -o fred fred.f
>/usr/lib/fcom1.31 -v -EL -g0 -O0 -automatic -XS/tmp/ctmsta12713 -t
>/tmp/ctmfa127
>13 fred.f
>fred.f:
>   MAIN:
>   fred:
>0.0u 0.1s 0:00 31% 107+191k 2+6io 6pf+0w
>/usr/lib/ugen1.31 -v -G 8 -EL -g0 -O0 /tmp/ctmfa12713 -o /tmp/ctmca12713
>-t /tmp
>/ctmsta12713 -temp /tmp/ctmgta12713
>0.0u 0.0s 0:00 20% 81+61k 3+7io 3pf+0w
>/usr/lib/as11.31 -v -G 8 -p0 -EL -g0 -O0 /tmp/ctmca12713 -o fred.o -t
>/tmp/ctmst
>a12713
>as1: MAIN__ fred_
>0.0u 0.0s 0:00 32% 74+67k 2+3io 3pf+0w
>/usr/bin/ld1.31 -o fred -B1.31 -G 8 -g0 -nocount /usr/lib/crt0.o1.31
>-count fred
>/usr/bin/ld1.31 -o fred -B1.31 -G 8 -g0 -nocount /usr/lib/crt0.o1.31
>-count fr/u
>sr/lib/libm.a1.31 -lc
>0.2u 0.7s 0:04 21% 70+228k 105+32io 2pf+0w
>temper> fred
> (5.000000,0.0000000E+00)


The above was a Mips FORTRAN release 1.31 bug, but has since been fixed
in our 2.0 release.  The output should be (13,11) though, not (15,10).
-- 
UUCP:	{ames,decwrl,prls,pyramid}!mips!lilian	(or lilian@mips.com)
DDD:	408-991-7848 Lilian Leung		(or 408-720-1700, Ext. 848)
USPS:	MIPS Computer Systems, 930 Arques, Sunnyvale, CA 94086-3650