From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-280491-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 7298 invoked by alias); 7 Apr 2009 15:45:18 -0000
Received: (qmail 6975 invoked by uid 48); 7 Apr 2009 15:45:00 -0000
Date: Tue, 07 Apr 2009 15:45:00 -0000
Message-ID: <20090407154500.6974.qmail@sourceware.org>
X-Bugzilla-Reason: CC
References: <bug-39678-15185@http.gcc.gnu.org/bugzilla/>
Subject: [Bug target/39678] std::transform is incorrect with std::multiples and bind2nd for complex<float>
In-Reply-To: <bug-39678-15185@http.gcc.gnu.org/bugzilla/>
Reply-To: gcc-bugzilla@gcc.gnu.org
To: gcc-bugs@gcc.gnu.org
From: "rguenth at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
X-SW-Source: 2009-04/txt/msg00649.txt.bz2



------- Comment #9 from rguenth at gcc dot gnu dot org  2009-04-07 15:44 -------
Wait - it's ok.

    class binder2nd
    : public unary_function<typename _Operation::first_argument_type,
       typename _Operation::result_type>
    {
    protected:
      _Operation op;
      typename _Operation::second_argument_type value;

_Operation is probably empty, so there are 4 bytes padding and the struct
is returned in a xmm0

(gdb) p $xmm0
$5 = {v4_float = {-9.04046813e+33, 4, 0, 0}

but we access the result like

        call   
_ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_
        movl    72(%rsp), %edx
        movq    %xmm0, 8(%rsp)
        movq    8(%rsp), %rax
        movl    %edx, 88(%rsp)
        movq    %rax, 80(%rsp)
        movss   88(%rsp), %xmm5
        movq    %rax, 64(%rsp)
        movss   84(%rsp), %xmm4
        movq    %rax, 96(%rsp)
        movl    %edx, 104(%rsp)
        .loc 5 1144 0
        movaps  %xmm4, %xmm0
        movaps  %xmm5, %xmm1
        movss   4(%rbx), %xmm3
        movss   (%rbx), %xmm2
        movss   %xmm4, 32(%rsp)
        movss   %xmm5, 16(%rsp)
        call    __mulsc3
        movq    %xmm0, 56(%rsp)
        movl    56(%rsp), %eax
        movl    60(%rsp), %edx


so you can see we simply use the lower 8 bytes of %xmm0 only ...
(supposedly thinking that the other half got loaded to %edx).

It's already broken at expansion:

(call_insn 67 66 68 11 t.C:13 (set (parallel:BLK [
                (expr_list:REG_DEP_TRUE (reg:DI 21 xmm0)
                    (const_int 0 [0x0]))
            ])
        (call (mem:QI (symbol_ref/i:DI
("_ZSt7bind2ndISt10multipliesISt7complexIfEES2_ESt9binder2ndIT_ERKS5_RKT0_")
[flags 0x1] <function_decl 0x7ffff4887d00 bind2nd>) [0 S1 A8])
            (const_int 0 [0x0]))) -1 (expr_list:REG_EH_REGION (const_int 0
[0x0])
        (nil))
    (expr_list:REG_DEP_TRUE (use (reg:DI 5 di))
        (expr_list:REG_DEP_TRUE (use (reg:DI 4 si))
            (nil))))

(insn 68 67 69 11 t.C:13 (set (reg:DI 92)
        (reg:DI 21 xmm0)) -1 (nil))


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|same                        |x86_64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678