I think the problem you are seeing may be caused by how the FORTRAN version of
the LAPACK library you are using was compiled. Using gfortran 4.8.0 (on Mac OS
10.8), I could reproduce the problem you saw if I compile LAPACK with the -O3
option for gfortran. If I recompile the LAPACK and reference BLAS library with
-fopenmp -O3, the problem goes away. There is a note in the gfortran manual
stating "-fopenmp implies -frecursive, i.e., all local arrays will be allocated
on the stack," so there may be local arrays used in some auxiliary routines
called by dsyevr for which the default setting of the compiler is causing them
to be allocated in a non-thread safe manner. In any case, allocating these on
the stack, which -fopenmp seems to do, will address this issue.
On Aug 18, 2013, at 4:34 AM, Daniel Strobusch <daniel.strobusch@Domain.Removed>
Dear LAPACK Team,
according to my testing LAPACKs dsyevr does not seem to be thread-safe. This
is in contrast to the statement "all routines in LAPACK-3.3 are now
thread-safe." from "http://www.netlib.org/lapack/lapack-3.3.0.html).
In multi-threaded application the routine produces (arbitrarily wrong
eigenvectors, although eigenvalues are ok).
I tried to discuss the problem on http://stackoverflow.com
where also a full example program is given, which demonstrates the issue. As
I'm not a Fortran programmer I can only provide an example in C. It was
tested to call the routine dsyevr via the LAPACKE interface and also
directly. After the test failed with optimized OpenBLAS, the netlib reference
LAPACK/BLAS was used to confirm the misbehavior of the program. The tests
were run on two different platform.
I assume there is still a bug in LAPACK concerning thread-safety. I would
appreciate if you could confirm the bug and of course correct it in further
versions. Contributions to the stackoverflow discussion are also welcome.
With best regards
Lapack mailing list