Sun Fortran v1.4 bugs
Reg Clemens
reg at afwl.af.mil
Thu Jun 13 05:40:00 AEST 1991
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.
More information about the Comp.sys.sun
mailing list