Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sdd.hp.com!elroy.jpl.nasa.gov!lll-winken!sun-barr!newstop!exodus!exodus-bb!khb From: khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) Newsgroups: comp.lang.fortran Subject: Re: Sun Fortran v1.4 bugs Message-ID: Date: 29 May 91 21:12:17 GMT References: <1991May29.013534.29469@ariel.unm.edu> Sender: news@exodus.Eng.Sun.COM Organization: Sun MegaSystems Lines: 106 In-reply-to: john@spectre.unm.edu's message of 29 May 91 01:35:34 GMT Thanks for bringing this to our attention John. We are contacting him directly, 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. > Reg.Clemens > clemens@afwl.af.mil I trust that the author will either track down the source of the numerical problem, or will chat with me directly. ---- Thank you for bringing these problems to our attention. Feel free to communicate directly with us (via the AC or email). -- ---------------------------------------------------------------- Keith H. Bierman keith.bierman@Sun.COM| khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043