Path: utzoo!utgpu!cunews!bnrgate!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request From: reg@afwl.af.mil (Reg Clemens) Newsgroups: comp.sys.sun Subject: Re: Sun Fortran v1.4 bugs Keywords: Software Message-ID: <3803@brchh104.bnr.ca> Date: 12 Jun 91 19:40:00 GMT Sender: news@brchh104.bnr.ca Organization: Sun-Spots Lines: 105 Approved: Sun-Spots@rice.edu X-Original-Date: Thu, 6 Jun 91 04:55:53 MDT X-Sun-Spots-Digest: Volume 10, Issue 107, message 9 X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu 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@afwl.af.mil -soon to be - clemens@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.