mikem+@andrew.cmu.edu (Michael Meyer) (10/04/89)
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)
lilian@mips.COM (Lilian Leung) (10/06/89)
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