Compiling with VS2012 and working with the DirectXMath library, I encountered an issue where it appeared that the compiler wasn't aligning my XMMATRIX. I simplified the issue down to the following.
#include <DirectXMath.h>
using namespace DirectX;
int _tmain(int argc, _TCHAR* argv[])
{
auto m1 = XMMatrixIdentity();
auto m2 = XMMatrixIdentity();
auto t1 = XMMatrixTranspose( m1 ); // sometimes access violation occurs here
auto t2 = XMMatrixTranspose( m2 ); // or sometimes here
return 0;
}
Re-running the code over and over will sometimes cause an "Access violation reading location 0xFFFFFFFF" on the first transpose, sometimes on the second.
I've figured out this is due to the fact that m1 and m2 are not being properly aligned. Replacing "auto" with "XMMATRIX" seems to solve the issue, so my suspicion is a compiler bug, but its also possible that I'm doing something wrong, or not enabling some option.
Is there something wrong with my code or is this a compiler bug?
The definition for XMMATRIX has the following in the header file (xnamath.h), although this could be different in your version.
// Matrix type: Sixteen 32 bit floating point components aligned on a
// 16 byte boundary and mapped to four hardware vector registers
#if (defined(_XM_X86_) || defined(_XM_X64_)) && defined(_XM_NO_INTRINSICS_)
typedef struct _XMMATRIX
#else
typedef _DECLSPEC_ALIGN_16_ struct _XMMATRIX
#endif
So XMMATRIX is defined with __declspec(align(16)) (if you look through the header files it does reduce to this), which is a Microsoft specific extension. It's not a macro. This means it's a compiler bug, the compiler is failing to propagate these proprietary attributes to variables defined with the auto keyword.
It's probably best to just avoid the use of the auto keyword in this case, it's probably neater than explicitly adding the declspec yourself.