Hi,
I've tracked down a segmentation fault in my application to the compiler generating a "movdqa %xmm1,0x1d8(%rsp)" instruction. This happens during initialization of an object
class mcrx::hilbert_ordering {
hilbert::hilbert_state state_[hilbert::cell_code::maxlevel_];
uint8_t n_;
...
};
where the "hilbert_state" object is:
class hilbert::hilbert_state {
uint8_t data_;
hilbert_state() { write_data(0, 1, 0, 0, 0); };
void write_data(uint8_t dim1, uint8_t dim2,
uint8_t a1, uint8_t a2, uint8_t a3) {
data_ = dim1 | (dim2<<'\\x02') |
(a1<<'\\x04') | (a2<<'\\x05') | (a3<<'\\x06'); };
...
};
The default constructor sets data_=0x04. The compiler tries to accomplish the initialization of the array of hilbert_state by doing the following (I think I have extracted all relevant instructions.)
mov $0x4040404,%eax
movd %eax,%xmm0
pshufd $0x0,%xmm0,%xmm1
movdqa %xmm1,0x1d8(%rsp)
The problem is that it uses an instruction that requires the operand be 16-byte aligned, but it isn't (as evidenced by the 0x1d8). This causes a segmentation fault.
I tried to extract the relevant code into a short example, but when I do that, the complier only generates movdqa when the array is aligned, and uses movdqu when it's not.
Manually setting the alignment of the array to 16 with __declspec(align(16)) makes the problem go away. Explicitly setting it to 1 doesn't make the compiler generate the unaligned instruction.
Does this sound like a compiler bug? If not, any ideas why this might be happening?
This is withicpc: (ICC) 12.0.3 20110309 on a: Linux 2.6.18-194.32.1.el5 #1 SMP Thu Jun 30 09:34:45 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux.
Thanks,
/Patrik
