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

2006-02-04 Thread Andrew Pinski
On Feb 3, 2006, at 8:23 PM, tbp wrote: 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. signs_all[4] = { !(sx 0),

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

2006-02-04 Thread tbp
On 2/4/06, Andrew Pinski [EMAIL PROTECTED] wrote: Dale Johannesen and I came up with a patch to the C++ front-end for this except it did not work with some C++ cases. Ah, so i'm not totally inane. Is there a PR i can track for this one?

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

2006-02-04 Thread Dale Johannesen
On Feb 4, 2006, at 7:06 AM, Andrew Pinski wrote: signs_all[4] = { !(sx 0), !(sy 0), !(sz 0), 0 }, C++ front-end produces: cleanup_point const int signs_all[4] = {0};; cleanup_point signs_all[0] = (int) sx = 0 ; Unknown tree: expr_stmt signs_all[1] = (int) sy = 0 ;

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

2006-02-03 Thread tbp
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