LAPACK Archives

[Lapack] xLAMCH

I personally think we were not that bad in term of documentation.

Here what we wrote


  6) Thread safety: Removed all the SAVE and DATA statements (or provided
     alternate routines without those statements), increasing reliability
     on SMPs.

     All the LAPACK routines are now thread safe except {s,d}LAMCH and the
     triplet {c,d,s,z}lacon.f, {d,s}lasq3.f and {d,s}lasq4.f. By thread
     safe, we mean that your LAPACK library wil be thread safe provided
     that your compiler is. Regarding the 10 routines still containing DATA
     or SAVE statement: {s,d}LAMCH can be manually replace by thread-safe
     routines (e.g. using F90).
     {c,d,s,z}lacon.f, {d,s}lasq3.f and {d,s}lasq4.f are left in LAPACK for
     backward compatibility, they are flagged as deprecated, and represent
     dead codes in this current release (v3.1).


So we are not saying thread safe but "increasing reliability on SMPs" and 
explicitly explain how to be thread-safe. Namely: "manually replace 

I think we're good on the documentation
( until we change the routine ... )


On Sat, 1 Sep 2007, James Demmel wrote:

Sven Hammarling wrote:
Dear LAPACKers,

Following the helpful messages from Jeremy Barnes, I would like to press
the request, that I have made in the past, that we supply an IEEE
version of xLAMCH.  My colleague, Mick Pont, has pointed out that we
have already moved xLAMCH into the INSTALL directory, and so we could
test for an IEEE machine at install time using the current xLAMCH and
move a hard coded version into SRC if the machine parameters are IEEE.

Best wishes,

Lapack mailing list

I am happy with Sven's solution.

How well documented was the potential thread safety problem in the last
Let's make sure the documentation is appropriately updated.


Lapack mailing list

<Prev in Thread] Current Thread [Next in Thread>

For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or