Bugreport on dlamch and -ffloat-store

[anoko]

Dear people,

I'm trying to use the CLAPACK package, especially zgesvd to do sv decomposition, but found that the zgesvd_ function hangs. When debugging the library, I found that it was actually the dlamch_ (dlamch1 or dlamch2 actually) function that stucks. When searching for solutions, I found that the same problem occured in the Fortran version on certain platforms (among x86), and that compiling with the -ffloat-store would solve the problem. That did indeed solve the problem.

Would it be an idea to compile the library with -ffloat-store as default?

My platform is a dual core Intel x86 machine, gcc --version: "gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)" and CLAPACK-3.1.1 with the internally provided blas library.

Kinds regards,
André

[Julien Langou]

Thanks a lot for your comment, actually, you might not want to compile the whole library with this flag,
but only xLAMCH routine. To do this set up your flag in the Make.inc in the NOOPT variable.
-julien.

[godzilla_blue]

I had a similar problem and the ffloat bit did not help.

What I got (calling dlamch via call to dgelss) was that on the first call to DLAMC3 (from DLAMC1, line 220 of dlamach.f) DLAMC3 returned NAN instead of A+ONE. Note printing the value of DLAMC3 inside DLAMC3 before returning it was correct, despite being NAN on return.

I fixed it by just adding an "unnecessary" call to DLAMC3 before the loop, but this seems very odd since it's such a simple routine and there don't seem to be any issues with variables not being used before being called or etc.

I only saw the problem when calling dgelss from a routine compiled into a library (same machine, same compiler - intel Mac using gcc4.5), and not when called directly, but it doesn't seem that should make any difference.

[godzilla_blue]

never mind - there was a nominally unrelated bug I found elsewhere that I would not have thought would have affected this but fixing it seems to have removed this anomaly.