x86-64, I definitely can't make sense out of that

[tbp <tbptbp at gmail dot com>]

As i coulnd't understand why g++ insisted on spitting movq $0, <stack>
only to rewrite the same place a few cycles behind (with a different
width), i've made a testcase and now 20mn later i'm even more puzzled.

#include <xmmintrin.h>
#include <stdio.h>

struct dir_t { __m128 x,y,z; };

int creative_codegen(const struct dir_t *dir) {
	const int
		sx = _mm_movemask_ps(dir->x), sy = _mm_movemask_ps(dir->y), sz =
_mm_movemask_ps(dir->z),
		signs_all[4] = { !(sx > 0), !(sy > 0), !(sz > 0),  0 },
		coherent = (((sx == 0) | (sx == 15)) & ((sy == 0) | (sy == 15)) &
((sz == 0) | (sz == 15)));

	if (coherent) { int i; for (i=0; i<4; ++i) printf("%d",signs_all[i]); }
	return coherent;
}

int main(int argc, void **argv) { return creative_codegen((struct
dir_t*)argv); }

with g++ -O2 (4.0.3, 4.2.0 20060121)
[...]
  40056d:       movq   $0x0,0x10(%rsp) # ?
  400576:       movq   $0x0,0x18(%rsp) # ??
[...]
  40058b:       movq   $0x0,(%rsp) # ???
  400593:       movq   $0x0,0x8(%rsp) # ok
[...]
  40059f:       mov    %eax,0x10(%rsp) # ok
[...]
  4005b1:       mov    %eax,0x14(%rsp) # ok
[...]
  4005c4:       mov    %eax,0x18(%rsp) # ok

If compiled  with gcc, there's no such preliminary movq.

So the question is, what is so obviously flying way over my head?