Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!mips!pacbell.com!att!news.cs.indiana.edu!ariel.unm.edu!spectre.unm.edu!john From: john@spectre.unm.edu (John Prentice) Newsgroups: comp.lang.fortran Subject: Sun Fortran v1.4 bugs Message-ID: <1991May29.013534.29469@ariel.unm.edu> Date: 29 May 91 01:35:34 GMT Organization: Dept. of Math & Stat, University of New Mexico, Albuquerque Lines: 164 Originator: john@spectre.unm.edu I am posting this for someone else. Please respond directly to him. ----------- OK folks, guess its time to start enumerating the bugs in the new release of SunFortran [ SunFortran v1.4 ]. From what I've seen so far the compiler is much better than 1.3.1 and 1.4beta. That said, my first test was to compile the SLATEC Math library, and there were several failures. [ for those of you not familiar with SLATEC, it currently stands at about 270000 lines of Fortran, and contains a set of Quick Checks that amount to another 44000 lines of code. It is used on everything from PCs to CRAYs ] From what I've seen so far, there still seem to be optimizer problems, so if you want the right answer (as opposed to the wrong answer but much faster) you should NOT turn on the optimizer. Pity, since some of the QC were speeded up anywhere from 2x to 5x by saying -O or -fast. So, to date I have seen THREE failures. Two are related to COMPLEX ARITHMETIC, and the third is not. The two bugs involving COMPLEX cause the codes to blow off the machine [ at least you know you have a problem ], the other one only occurs with -fast and just gives the wrong answer... I have not investigated it in detail yet, but it could be just due to the (documented) fact that -fast handles underflow differently. Examples of the two COMPLEX ARITHMETIC bugs follow. The first will occur when the code is compiled with either -O or -fast. The other one only with -fast. *** BUG 1 *** The following piece of code demos a problem with AIMAG. In the actual code AIMAG was not on a WRITE statement, but putting it theres makes things easier to demo. Note that the code `does the right thing' for -g and [no optimization] but dies for -O or -fast. The problem seems related to the fact that `C' is dimensioned, since if you un-dimension C (four places) this test will run correctly for all optimization levels. Environment: SS2, SUNOS4.1.1, SunFortran v1.4 -------------------------------------------- program test complex c(1) c c open (unit=6, file='output', form='formatted') c c(1) = (-2.0, -1.0) write (6, '(2e20.6)') c c write (6, '(2e20.6)') real(c(1)), aimag(c(1)) stop end -------------------------------------------- clemens% f77 -g test.f test.f: MAIN test: clemens% a.out clemens% cat output -0.200000E+01 -0.100000E+01 -0.200000E+01 -0.100000E+01 -------------------------------------------- clemens% f77 test.f test.f: MAIN test: clemens% a.out clemens% cat output -0.200000E+01 -0.100000E+01 -0.200000E+01 -0.100000E+01 -------------------------------------------- clemens% f77 -O test.f test.f: MAIN test: clemens% a.out *** Segmentation Violation = signal 11 code 3 Traceback has been recorded in file: /home/reg/FORTRAN/./a.out.trace Note: Line numbers for system and library calls may be incorrect Abort (core dumped) clemens% cat output -0.200000E+01 -0.100000E+01 -0.200000E+01clemens% ^^^^^^^^^^^^^^^^^^^^ note missing output -------------------------------------------- clemens% f77 -fast test.f test.f: MAIN test: clemens% a.out *** Segmentation Violation = signal 11 code 3 Note: this program was linked with -fast or -fnonstd and so may have produced nonstandard floating-point results. Sun's implementation of IEEE arithmetic is discussed in the Numerical Computation Guide. Traceback has been recorded in file: /home/reg/FORTRAN/./a.out.trace Note: Line numbers for system and library calls may be incorrect Abort (core dumped) clemens% cat output -0.200000E+01 -0.100000E+01 -0.200000E+01clemens% ^^^^^^^^^^^^^^^^^^^^ note missing output -------------------------------------------- cat a.out.trace Note: Line numbers for system and library calls may be incorrect Begin traceback... Called from [func: (null)], at 0xf76b2c4c, args=0xb 0x3 0xf7793a44 0xf78022a8 Called from [func: _MAIN_], at 0x2370, args=0xc0000000 0xf7fffc4c 0x6 0xf779ece4 Called from [func: (null)], at 0xf7740c38, args=0x0 0x2ab0c 0x1 0x2e000000 Called from [func: start], at 0x2064, args=0x0 0x10 0xf7fffd9c 0x28000 End traceback... Note: Line numbers for system and library calls may be incorrect Begin traceback... Called from [func: (null)], at 0xf76b2c4c, args=0xb 0x3 0xf7793a44 0xf78022a8 Called from [func: _MAIN_], at 0x23f4, args=0xc0000000 0xf7fffc4c 0x6 0xf779ece4 Called from [func: (null)], at 0xf7740c38, args=0x0 0x28a04 0x1 0x2e000000 Called from [func: start], at 0x2064, args=0x0 0x10 0xf7fffd9c 0x26000 End traceback... -------------------------------------------- *** BUG 2 *** Here is another bug in COMPLEX ARITHMETIC that appears to involve doing a logical comparison to a pure imaginary number, and only occurs when the compile is done with -fast. Consider the following test problem ----------------------------- program test complex a, czero data a / (0., 1.e-6) / data czero / (0., 0.) / c c if (a.ne.czero) goto 100 stop 100 stop 100 end ----------------------------- This program will run to completion if the code is NOT compiled with -fast. If compiled with -fast, the code blows off the machine with *** Bus Error = signal 10 code 2 If you change the data statement for `a' to read:- data a / (1., 1.e-6) / So that `a' is no longer PURE imaginary, it no longer dies... Don't know if this is the whole story, but its a start. Environment: SS2, SUNOS4.1.1, SunFortran v1.4 -- Reg.Clemens clemens@afwl.af.mil