Using Eigen 3.3rc1 on windows 7, 64 bit with Visual Studio 2013,
EIGEN_IDEAL_MAX_ALIGN_BYTES is defined as 32 when AVX is enabled.
aligned_malloc() still takes the code path given by EIGEN_MALLOC_ALREADY_ALIGNED
which results in 16-byte aligned memory.
This results in a crash in an line like
Eigen::VectorXd x = Eigen::VectorXd::Zero(n)
which traces down to a pstore.
Could it be that line 52 of Memory.h should read:
|| (EIGEN_OS_WIN64 && (EIGEN_DEFAULT_ALIGN_BYTES == EIGEN_IDEAL_MAX_ALIGN_BYTES)) \
|| (EIGEN_OS_WIN64 && (EIGEN_DEFAULT_ALIGN_BYTES == 16)) \
I'm not sure, especially since the gcc and clang paths have the same condition (i.e. `== 16`). And as far as I remember the essential unit tests all work with gcc and clang and AVX enabled (currently I'm on a non-AVX cpu, I'll try that when I get home).
This is strange because EIGEN_MALLOC_ALREADY_ALIGNED is defined only if EIGEN_DEFAULT_ALIGN_BYTES == 16 (Memory.h, line 52), and in Macros.h line 772 we have:
#if EIGEN_IDEAL_MAX_ALIGN_BYTES > EIGEN_MAX_ALIGN_BYTES
#define EIGEN_DEFAULT_ALIGN_BYTES EIGEN_IDEAL_MAX_ALIGN_BYTES
#define EIGEN_DEFAULT_ALIGN_BYTES EIGEN_MAX_ALIGN_BYTES
so in your case, EIGEN_DEFAULT_ALIGN_BYTES should be defined to 32, and thus EIGEN_MALLOC_ALREADY_ALIGNED would be disabled.
Are you sure you are using 3.3rc1? Could you check the value of EIGEN_DEFAULT_ALIGN_BYTES?
Using your suggestions:
was set correctly (32) for the static lib of which the code is part.
The application itself, however, did not have the AVX instruction set enabled.
This caused the functions in the .lib to use the non-32 byte version of the allocation routines.