laporte@sobmips.UUCP (p.laporte) (02/02/90)
We have found what we think is a bug in the fortran compiler (version 2.0)
Here is a small program that demonstrate the problem. When we use the
optimiser we get incorrect results when doing a simple addition.
Maybee someone at mips could tell me if they were aware of this bug and
if there is a patch for it.
Tks
-----
implicit double precision(a-h, o-z)
common ia,r(12),tb
data tb / 0.02d0 /
r(4) = 4.0
r(5) = 1.0
r(6) = 2.0
r(7) = 3.0
write (*,10) r(4),r(5),r(6),r(7)
r1 = r(5)+r(6)
r2 = r(5)+r(7)
r3 = r(5)+r(6)+r(7)
write(*,20) r1, r2,r3
write(*,20) r(5)+r(6),r(5)+r(7),r(5)+r(6)+r(7)
10 format ( " R(4)=",F8.5 " R(5)=",F8.5 " R(6)=",F8.5
1 " R(7)=",F8.5 //)
20 format ( " R(5)+R(6)=", F8.5/ " R(5)+R(7)=",F8.5/
1 " R(5)+R(6)+R(7)=",F8.5 // )
stop
end
--------------------------------------------------
without any option
R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
--------------------------------------------------
with -O0 option
R(4)= 4.00000 R(5)= 1.00000 R(6)= 2.00000 R(7)= 3.00000
R(5)+R(6)= 3.00000
R(5)+R(7)= 4.00000
R(5)+R(6)+R(7)= 6.00000
R(5)+R(6)= 3.00000
R(5)+R(7)= 4.00000
R(5)+R(6)+R(7)= 6.00000
--------------------------------------------------
with -O1 option
R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
--------------------------------------------------
with -O2 option
R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
--------------------------------------------------
with -O3 option
R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
R(5)+R(6)= 4.00000
R(5)+R(7)= 5.00000
R(5)+R(6)+R(7)= 7.00000
--------------------------------------------------
with -O0 and -g options
R(4)= 4.00000 R(5)= 1.00000 R(6)= 2.00000 R(7)= 3.00000
R(5)+R(6)= 3.00000
R(5)+R(7)= 4.00000
R(5)+R(6)+R(7)= 6.00000
R(5)+R(6)= 3.00000
R(5)+R(7)= 4.00000
R(5)+R(6)+R(7)= 6.00000
Pierre Laporte
{attcan,mcgill-vision,telly}!sobeco!laportelilian@mips.COM (Lilian Leung) (02/02/90)
In article <1990Feb1.170639.15889@sobmips.UUCP> laporte@sobmips.UUCP (p.laporte) writes: >We have found what we think is a bug in the fortran compiler (version 2.0) > >Here is a small program that demonstrate the problem. When we use the >optimiser we get incorrect results when doing a simple addition. > >Maybee someone at mips could tell me if they were aware of this bug and >if there is a patch for it. > >Tks > >----- > implicit double precision(a-h, o-z) > > common ia,r(12),tb > data tb / 0.02d0 / > r(4) = 4.0 > r(5) = 1.0 > r(6) = 2.0 > r(7) = 3.0 > write (*,10) r(4),r(5),r(6),r(7) > r1 = r(5)+r(6) > r2 = r(5)+r(7) > r3 = r(5)+r(6)+r(7) > write(*,20) r1, r2,r3 > write(*,20) r(5)+r(6),r(5)+r(7),r(5)+r(6)+r(7) >10 format ( " R(4)=",F8.5 " R(5)=",F8.5 " R(6)=",F8.5 > 1 " R(7)=",F8.5 //) >20 format ( " R(5)+R(6)=", F8.5/ " R(5)+R(7)=",F8.5/ > 1 " R(5)+R(6)+R(7)=",F8.5 // ) > stop > end > >-------------------------------------------------- > without any option > R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > >-------------------------------------------------- > with -O0 option > R(4)= 4.00000 R(5)= 1.00000 R(6)= 2.00000 R(7)= 3.00000 > > > R(5)+R(6)= 3.00000 > R(5)+R(7)= 4.00000 > R(5)+R(6)+R(7)= 6.00000 > > > R(5)+R(6)= 3.00000 > R(5)+R(7)= 4.00000 > R(5)+R(6)+R(7)= 6.00000 > > >-------------------------------------------------- > with -O1 option > R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > >-------------------------------------------------- > with -O2 option > R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > >-------------------------------------------------- > with -O3 option > R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > > R(5)+R(6)= 4.00000 > R(5)+R(7)= 5.00000 > R(5)+R(6)+R(7)= 7.00000 > > >-------------------------------------------------- > with -O0 and -g options > R(4)= 4.00000 R(5)= 1.00000 R(6)= 2.00000 R(7)= 3.00000 > > > R(5)+R(6)= 3.00000 > R(5)+R(7)= 4.00000 > R(5)+R(6)+R(7)= 6.00000 > > > R(5)+R(6)= 3.00000 > R(5)+R(7)= 4.00000 > R(5)+R(6)+R(7)= 6.00000 > > >Pierre Laporte >{attcan,mcgill-vision,telly}!sobeco!laporte This is a verified bug under our version 2.0 FORTRAN compiler. It has been fixed in our 2.10 version. -- 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
calvin@dinkum.sgi.com (Calvin H. Vu) (02/02/90)
In article <1990Feb1.170639.15889@sobmips.UUCP> laporte@sobmips.UUCP (p.laporte) writes: >We have found what we think is a bug in the fortran compiler (version 2.0) >Here is a small program that demonstrate the problem. When we use the >optimiser we get incorrect results when doing a simple addition. This is what I got (everything compiled with -O2): MIPS 1.21 release: R(4)= 4.00000 R(5)= 1.00000 R(6)= 2.00000 R(7)= 3.00000 R(5)+R(6)= 2.00000 R(5)+R(7)= 4.00000 R(5)+R(6)+R(7)= 5.00000 R(5)+R(6)= 2.00000 R(5)+R(7)= 4.00000 R(5)+R(6)+R(7)= 5.00000 MIPS 1.31 release: (original) R(4)= 4.00000 R(5)= 2.00000 R(6)= 0.00000 R(7)= 3.00000 R(5)+R(6)= 4.00000 R(5)+R(7)= 5.00000 R(5)+R(6)+R(7)= 7.00000 R(5)+R(6)= 4.00000 R(5)+R(7)= 5.00000 R(5)+R(6)+R(7)= 7.00000 MIPS 1.31 release: (modified - SGI 3.2 release) R(4)= 4.00000 R(5)= 1.00000 R(6)= 2.00000 R(7)= 3.00000 R(5)+R(6)= 3.00000 R(5)+R(7)= 4.00000 R(5)+R(6)+R(7)= 6.00000 R(5)+R(6)= 3.00000 R(5)+R(7)= 4.00000 R(5)+R(6)+R(7)= 6.00000 All MIPS 2.0 releases (one original from MIPS and two SGI's souped up versions) give the correct results. So that leaves a question: Are you sure you have the MIPS 2.0 release of Fortran ? I remember they had a problem with register allocation in the assembler that was fixed in the 2.0 release. That is most likely the problem you ran into. Try to get the new assembler from MIPS if you can. I still don't know why you have this problem with your 2.0 release though since the plain-vanilla 2.0 release MIPS sent us no longer has this bug. Hmmmm, suddenly I realized that I had 7 versions of the Fortran compiler on my machine just for historical comparisons. >Pierre Laporte >{attcan,mcgill-vision,telly}!sobeco!laporte Calvin Vu
laporte@sobeco.com (p.laporte) (02/18/90)
Using structures in fortran we have discovered a bug in the compiler.
When compiling this simple program
structure /typea/
character*11 key
end structure
record /typea/ rec
rec(1) = 0
rec.key = '0001'
write(*,*) rec.key
stop
end
We get the following message
Fatal error in: /usr/lib/cmplrs/f77/fcom - core dumped
I realize that the line rec(1) = 0 is illegal but ....
If someone at mips (Lilian) could tell us if they know about this bug
and if a fix is available. We are using version 2.0 of the f77 compiler.
Also i am looking for a way to initialyse a structure without referencing
all the elements. Particularely i need to initialyse the positions that
i defined with %fill to put null in them.
Tks
Pierre Laporte
laporte@Sobeco.comdds@hare.udev.cdc.com (dd say x-2636) (02/20/90)
Does anyone out there remember anything about a bug in f77 (version 2.0 I think) that occurs when one uses optimization level 3. Any info on this and any other version 2.0 f77 bug would be greatly appreciated. Thaks in advance, D. Say
lilian@mips.COM (Lilian Leung) (02/21/90)
In article <1990Feb17.213900.26927@sobeco.com> laporte@sobeco.com (p.laporte) writes: >Using structures in fortran we have discovered a bug in the compiler. > >When compiling this simple program > > structure /typea/ > character*11 key > end structure > record /typea/ rec > > rec(1) = 0 > rec.key = '0001' > write(*,*) rec.key > stop > end > >We get the following message > >Fatal error in: /usr/lib/cmplrs/f77/fcom - core dumped > This has been filed as a bug and will be fixed in our later version. Not in our 2.10 release though. > >Also i am looking for a way to initialyse a structure without referencing >all the elements. Particularely i need to initialyse the positions that >i defined with %fill to put null in them. > I don't quite understand your question here. Currently you can initialize any record element you like by doing something like structure /typea/ character*11 key /'abcde'/ integer i1 /1/ integer i2 real r3 /2.0/ double precision d4 end structure record /typea/ rec If the above is not what you want, please give us a call and provide us with more details. -- 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
laporte@sobeco.com (p.laporte) (03/28/90)
The following program
character*10 mot
double precision d
real f
mot = '4, '
read(mot,11) i
11 format(i)
write(*,*) 'i=',i
read(mot,21) f
21 format(f)
write(*,*) 'f=',f
read(mot,31) d
31 format(d)
write(*,*) 'd=',d
end
gives the following results
i= 4
f= 4.0000000E-07
d= 4.0000000000000004E-16
Of course the results for f and d re wrong.
Is this fixed in version 2.10 of the compiler ?
We are using version 2.0
Pierre Laporte
laporte@Sobeco.comkhb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) (03/29/90)
In article <1990Mar28.133559.20912@sobeco.com> laporte@sobeco.com (p.laporte) writes:
.... bad code
gives the following results
i= 4
f= 4.0000000E-07
d= 4.0000000000000004E-16
Of course the results for f and d re wrong.
Is this fixed in version 2.10 of the compiler ?
I suggest that you reread section 13 of x3.9-1978 again. The implied .
is not where you think it is.
If you write the code as
character*10 mot
double precision d
real f
mot = '4, '
read(mot,*) i
write(*,*) 'i=',i
read(mot,*) f
write(*,*) 'f=',f
read(mot,*) d
write(*,*) 'd=',d
end
I think you will be much happier with the results.
--
Keith H. Bierman |*My thoughts are my own. !! kbierman@Eng.Sun.COM
It's Not My Fault | MTS --Only my work belongs to Sun* kbierman%eng@sun.com
I Voted for Bill & | Advanced Languages/Floating Point Group
Opus | "When the going gets Weird .. the Weird turn PRO"