I have the following code:
#include <xmmintrin.h>
#include <vector>
struct Vec { __m128 m; };
std::vector<__m128> foo1;
std::vector<Vec> foo2; // Error C2719
I get C2719 in the designated line when I try to compile this. I'm confused about this. How can this be solved Do I have to write
struct Vec { float m[4]; };
and change all methods and operators (not shown) that work on the member to first load m with _mm_load_ps(), call some other intrinsics, then store it back using _mm_storeu_ps() This would be a lot of work, and I don't wont to do it if there's a better way.
How to put a struct with __m128 member in a std::vector?
DeepaSubramanian
I agree with Brian. Its strange.
Place a bug here, I am sure you get an answer:
http://lab.msdn.microsoft.com/productfeedback/Default.aspx
asifBasha
Interesting. Why vector<__m128> works and vector<Vec> doesn't escapes me. Even when struct Vec is modified with __declspec(align(16)) (a redundancy, admittably), you still get an error.
This difference in behavior could be a compiler bug (it could be argued that the foo1 definition should also issue C2719), but I have doubts as to whether std::vector is designed to maintain proper alignment. std::vector does its own memory management that appears to disregard special alignment requirements.
Personally, I would forgive the compiler as __m128 must be 16-byte aligned in order to work and instead use a plain C++ array over std::vector. Once you do this, you don't need to resort to packing/unpacking floats as you show above.
e.g. Vec* foo2 = new Vec[100];
Brian
chrismoo
There's room for some healthy paranoia with the Gnu compiler.
I'm wondering if the Pentium IV CPU forgives unaligned accesses with SSE/SSE2 instructions just as it does with accesses on the usual (integer) instructions (at the cost of a significant number of extra cycles). If so, then my next question would be whether the Gnu version of std::vector is producing unaligned memory accesses.
If unaligned accesses don't exist under the Gnu compiler, then that compiler has an advantage over Microsoft's in this scenario. If they do exist, then Microsoft's compiler is doing a better job since it issued an appropriate diagnostic.
Bria
Tejas34
Thank you both for your answers. Yes, I know that __m128 must be aligned. I was confused because the code was originally compiled on a different platform with the GNU compiler, and it worked. I conclude that it is possible, though it probably needs some compiler magic that Visual C++ just doesn't have.
Anyway, I decided to apply the workaround I spoke of in my original post. While being a lot of work, the code gets a cleanup that way, which is always a good thing.