Description of problem: Two files in the in Lapack package is build with too aggressive optimaze flags. The files in question is dlamch.f and slamch.f. These files are used to determine single and double precision machine parameters. Version-Release number of selected component (if applicable): lapack-3.0-25 How reproducible: Try to run the dlamctst program from the Lapack tarball. Steps to Reproduce: $ g77 -o dlamchtst dlamchtst.f -lm -lblas -llapack $ ./dlamchtst Actual results: It just hangs. Expected results: Produce this output: Epsilon = 2.22044605E-16 Safe minimum = 2.22507386E-308 Base = 2. Precision = 4.4408921E-16 Number of digits in mantissa = 53. Rounding mode = 0. Minimum exponent = -1021. Underflow threshold = 2.22507386E-308 Largest exponent = 1024. Overflow threshold = 1.79769313E+308 Reciprocal of safe minimum = 4.49423284E+307 Additional info: This works: $ g77 -c -Os dlamch.f $ g77 -o dlamchtst dlamchtst.f -lm -lblas dlamch.o $ ./dlamchtst Epsilon = 2.22044605E-16 Safe minimum = 2.22507386E-308 Base = 2. Precision = 4.4408921E-16 Number of digits in mantissa = 53. Rounding mode = 0. Minimum exponent = -1021. Underflow threshold = 2.22507386E-308 Largest exponent = 1024. Overflow threshold = 1.79769313E+308 Reciprocal of safe minimum = 4.49423284E+307 The rpm package is compiled with the -O2 flag. A patch to the spec file which fix the problem is attached.
Created attachment 106324 [details] Patch to lapack.spec Patch to lapack.spec to fix the problem.
Thank you for your notice. The problem was fixed. IV
The -O2 is "safe" optimization and should work. (It used to with previous versions of gcc.) In my opinion the actual issue is that gcc-3.4 is not ISO-compliant with regard to excessive presision. I think that reducing optimization helps here is purely fortuous. The fix would be to add -ffloat-store flag to FFLAGS and keep -O2. See bugs: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138791 and https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=138683 I still think that this is a gcc issue. Sincerely, Dmitri.
Solved with -27, closing now.
*** Bug 139404 has been marked as a duplicate of this bug. ***
*** Bug 146447 has been marked as a duplicate of this bug. ***
Could this be released as an update to FC3, please? Thanks.
Especially since this has been dropped from FC4, and so "upgrade to FC4" will never be a solution, and since there is already a corrected package, making it work in FC3 seems like the right thing to do. Given the "is broken" status and the several dups, I'm going to take the liberty of reopening this.
This bug is still present in Fedora Core 3. A scientific application that uses lapack stopped working in FC3. This is a very serious bug, since Linux is only good for scientific applications and most of them use lapack.
RedHat gave up on scientists (they dropped lapack from upcoming FC4 release). In a mean time you can get a working copy from: ftp://coffee.phys.unm.edu/pub/octave/RPMS/i386/ Dmitri. --
Dmitri -- lapack isn't gone. It's in Fedora Extras now. However, it'd still be nice for there to be an update for FC3.
this bug has been fixed in the latest lapack-3.0-26.fc3 update
Cool, thank you very very much, Red Hat folks.
The new fc3 version lapack-3.0-26.fc3 fixes this problem (and two other bugs) in fc3. Thank you for your notice. Ivana Varekova
Not to harass, but will there be an announcement mail for the fc3 update? It is very helpful to end-users when every update that appears in the tree has a matching mail message. Thanks!
Got the announcement. Thank you again! I hope this puts "Red Hat gave up on scientists" to rest.