Xref: utzoo comp.lang.fortran:3819 comp.os.msdos.programmer:1049 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!falstaff.mae.cwru.edu!jb From: jb@falstaff.mae.cwru.edu (Jim Berilla) Newsgroups: comp.lang.fortran,comp.os.msdos.programmer Subject: Re: MS Fortran 5.00 FP underflows Summary: MS Fortran 5 is buggy Keywords: Microsoft,Fortran Message-ID: <1990Sep21.082155.1743@usenet.ins.cwru.edu> Date: 21 Sep 90 08:21:55 GMT References: <1990Sep20.215410.4844@csun.edu> Sender: jb@falstaff.cwru.edu Organization: Case Western Reserve University Lines: 83 In article <1990Sep20.215410.4844@csun.edu> bcphyagi@Twg-S5.uucp (Stephen Walton) writes: [ He is having a problem with MS Fortran 5.00 floating point ] Well, sorry I can't help on that particular problem, but I can point out a few other bugs that cost me days of work. The compiler generates incorrect code in the following cases: 1. Using integer*1 variables in array subscripts. This test program illustrates the problem: integer*1 a(4,100) integer*1 i1,i2 read (*,*) i1,i2 a(i1,i2)=1 end The assembly code generated for line 4 shows the subscript is wrong: mov al,$S15_I1 ; move value of i1 to al cbw ; convert to word. ok so far. mov bx,ax ; move to index mov al,$S16_I2 ; move value of i2 to al shl al,1 ; instead of multiplying by 4, shift left shl al,1 ; by 2 bits. If i2=32, then the result ; is a signed -128, not unsigned +128. cbw ; converts byte to word, but sign extends. mov si,ax mov BYTE PTR $S14_A[bx-5][si],1 If you input i1=1 and i2=32 (both legal int*1 values) then the offset into the array is -132, before the start of the array. (or is it +65404? in any case, it's wrong.) 2. Setting an int*1 array to a default of #ff. May fail on other values. Another test program: integer*1 a(16),b a=#ff ! this doesn't work right. write (*,'(16(1xz2))') a do i=1,16 ! this doesn't work either. a(i)=#ff ! the loop is really only executed 8 times, end do ! it stores a word value each time. write (*,'(16(1xz2))') a a=-128 ! this really screws up. write (*,'(16(1xz2))') a b=#ff a=b ! this one works. write (*,'(16(1xz2))') a end Executing this program, I find that the first 3 methods of initializing the array fail: FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE 80 7F 80 7F 80 7F 80 7F 80 7F 80 7F 80 7F 80 7F FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF The compiler apparently tries to optimize by storing word values instead of byte values when the value is a constant, but doesn't generate the right constant. This occurs even with the /Od switch (Optimization off.) > >A while back, I complained about this to Microsoft, and they sent >me a new 87.lib for MS Fortran 4.1 and MS C 5.1. Should I use this >with MS Fortran 5.0 as well? I really don't feel like debugging >Microsoft's compiler for them. I tried to talk to Microsoft. These problems existed in 4.1, and I called them about it. After spending 15 minutes getting routed to someone who knew what Fortran was, the only response was something like "Gee, we don't know anything about that." I gave up. It's scarey to think that there are bugs like this in a mature product like Fortran. Especially when Fortran is used mostly in engineering, where things like bridges, nuclear reactors, and submarines are designed using Fortran programs. Fortunately, I still use my slide rule to check the answers. (Actully, I use an HP-15) -- Jim Berilla / jb@falstaff.cwru.edu / 216-368-6776 "My opinions are my own, except on Wednesday mornings at 9 AM, when my opinions are those of my boss."