Sun Fortran v1.4 bugs

[Reg Clemens]

Several weeks ago I posted a note to both Sunspots and to
comp.lang.fortran detailing two BUGS, and a third `problem' that I had
seen in compiling the SLATEC math library with SunFortran v1.4.  SLATEC is
one of my standard tests of a new compiler.  Both of the BUGS appear in
COMPLEX arithmetic.

Since the flood gates have only now been opened on the comp.sys.sun
postings I am repeating here the response that I received from someone in
the Fortran group at SUN.  He prefered that his name not be used on the
SUNSPOTS list.

					Reg.Clemens
					clemens at afwl.af.mil
			-soon to be -   clemens at plk.af.mil

-----------------------------------------------------------------------

|     ... but one assumes that the rest of the readers have some
|interest also.
|
|>   That said, my first test was to compile the SLATEC Math library, and
|>
|
|We do not have this code in house. We do employ NAG, IMSL and a wide
|variety of other codes in our validation suite (many of which cannot
|be discussed as they belong to folks who wish to remain anonymous). As
|is mentioned from time to time, we are always interested in acquiring
|more codes which have _good_test_suites_. Please contact me directly if
|you have code you'd like to submit. 
|
|>   (documented) fact that -fast handles underflow differently.
|
|The way -fast handles it, while non-ieee, was strongly requested by a
|large number of customers (and they've been able to get it with calls
|to abrupt_underflow() for quite some time; see the Numerical
|Computation Guide for details).
|
|   *** BUG 1 ***
|
|   The following piece of code demos a problem with AIMAG.  In the  actual
|
| This is an optimizer bug (which will appear
| at opt levels -O2 -> -O4).  It has been fixed in the next  
| release.  Here is what is going on:
|
|  It occurs when the function aimag is called with
|  an array element as the parameter (an erroneous deref
|  causes a segmentation violation). A workaround  is to put the array
|  element in a scalar and then  make the call.
|
| For example:
|
|      program test
|      complex c(1), a
|c
|c
|      open (unit=6, file='output', form='formatted')
|c
|      c(1) = (-2.0, -1.0)
|      write (6, '(2e20.6)') c
|c
|      a = c(1)
|      write (6, '(2e20.6)') real(c(1)), aimag(a)
|      stop
|      end
|
|
|This appears to be bug 1058033, which was just reported a few days
|ago. Aside from changing the code, you may use the following compiler
|switch to disable the offending bit of the optimizer
|
|       -Qoption iropt -On,complex 
|
|Put this after -fast -O4, and whathaveyou. This disables a bunch of
|complex arithmetic transformations, which are quite effective. So, my
|personal preference is to:
|
|	a) change the code as above
|	b) compile just the afflicted modules this way (make sure
|	   they reside in a file by themselves)
|	c) use the option mentioned above
|	d) give up on optimization
|
|(d) means tossing away factors of 2 in performance, so I am personally
|loathe to chose it.
|
|
|   *** 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.
|
|This is a bug in the libm.il file. The quick fix is to compile
|-nolibmil (-fast implies libmil). A slightly harder workaround is to
|edit your libmil file, deleting the offending function
|
|	!int
|	!_Fc_ne(x, y)
|	...
|
|Alternatively, wait a bit and contact your Answer Center and they
|should be able to provide you with a proper fix. The bug id is
|1060916, if you'd like to follow up with them, this is handy to have.