The issue occurred with Lapack+BLAS libraries shipped by Debian (libatlas3gf-base 3.6.0-22 + liblapack3gf 3.1.1-1), and also on those by Ubuntu (libblas3gf 1.2-2build1 + 3.2.1-2). Both are gfortran-built.

I (we) though that the non-orthogonal vectors isse got fixed (by Osni on Mon May 4th 2015) in the development version. So I cloned the fresh lapack (last commit from 17.6.2015) from https://github.com/live-clones/lapack and compiled it with GNU compilers.

1) If I run the test code provided by the user, in which DSYEVR is called with UPLO = 'U', I also get vectors that fail the orthogonality test.2) If I run the test code provided by the user but changing it to call DSYEVR with UPLO = 'L', everything works fine (i.e. the vectors are orthogonal)3) If I take the tridiagonal generated through 1) and run a separate tester everything works fine (i.e. the vectors are orthogonal).

There is something weird going on but I need to dig a little more before declaring it a bug. By the way, if there is a bug, I don't think it is related to bug 56: in bug 56, dsyevr is called with RANGE = 'I' (the IL-th through IU-th eigenvalues will be found), which triggers a different set of calculations, while in the test code provide by the user dsyevr is called with RANGE = 'A'.

I managed to reproduce the bug with our standalone tester, after saving the tridiagonal matrix generated by DSYTRD in DSYEVR with a lot of digits... Looking at the eigenvectors computed by DSTEMR (which is called by DSYEVR), it seems that the problem is related to some splitting of the tridiagonal. (I compared the eigenvectors computed by DSTEMR and DSTEVX to check that hypothesis. Note, however, that this bug is not related to bug 0056.)