Thank you for the clarification. I understand that the recommended solution is to migrate to the new LAPACK interface by defining ACCELERATE_NEW_LAPACK. What I find surprising is that simply including Accelerate/Accelerate.h and linking against Accelerate.framework still selects the deprecated interface unless this Apple-specific macro is defined. I suspect many scientific codes use Accelerate exactly this way: they call standard LAPACK routines such as zheev, zhegv, or zgemm, while the build system selects the BLAS/LAPACK library. The same source code can then be used on Linux and macOS. Requiring ACCELERATE_NEW_LAPACK introduces an Apple-specific build case that is easy to accommodate once known, but not something one would naturally expect. In our case this is especially problematic because the legacy routine returns INFO=0 and correct eigenvalues, while silently returning incorrect eigenvectors. There is no indication to the application that anything went wrong, so the error can propagate into scientific results. Would it not be preferable either for the new LAPACK interface to be the default for newly compiled applications, or at least for the legacy interface to emit a clear deprecation warning mentioning ACCELERATE_NEW_LAPACK? The workaround is straightforward once known, but discovering it only after silent numerical corruption is rather unexpected.

This might be related to a general bug in the apple implementation of diagonalization (zheev) that gets wrong eigenvectors in some specific cases. See test script below. zheev_upper_bug.c