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: <>; <>>; <<< Unknown tree: expr_stmt signs_all[1] = (int) sy <= 0 >>>; <<< Unknown tree: expr_stmt signs_all[2] = (int) sz <= 0 >>>; While the C

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 Andrew Pinski
On Feb 3, 2006, at 8:23 PM, tbp wrote: As i coulnd't understand why g++ insisted on spitting movq $0, 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), !(sy

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, 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 #include struct dir_t { __m128 x,y,z; }; int creative_codegen(const struct dir_t