From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-437765-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 9282 invoked by alias); 16 Dec 2013 19:20:26 -0000
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
Received: (qmail 9232 invoked by uid 48); 16 Dec 2013 19:20:22 -0000
From: "hjl.tools at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/56807] mingw32: Conflict between stack realignment and stack probe destroys function argument in EAX
Date: Mon, 16 Dec 2013 19:20:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.7.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl.tools at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-56807-4-4ug8SMhs0U@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-56807-4@http.gcc.gnu.org/bugzilla/>
References: <bug-56807-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01420.txt.bz2

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

--- Comment #19 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Anton Mitrofanov from comment #18)
> This patch is ok for mingw32 target but may produce incorrect code for
> x86_64 linux target in case of saving/restoring both rax and r10. In that
> case during restoring of rax register (in "if (r10_live && eax_live)" path
> of
> http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/i386/i386.
> c?r1=205860&r2=205859&pathrev=205860) we will make move from incorrect
> address [rsp + allocate - UNITS_PER_WORD] while the saved value will be at
> address [rsp + allocate + UNITS_PER_WORD]. Here is possible code that can be
> generated (by looking at current gcc source code):
> 
> // suppose rsp == 1000 here
> push rax // rsp == 992 ; [992] == rax
> push r10 // rsp == 984 ; [984] == r10
> mov rax, 400 // where 400 is allocate value
> call allocate_stack
> sub rsp, rax // rax == 400 so rsp == 584
> mov r10, [rsp + 400] // 584 + 400 == 984 ; r10 = [984]
> mov rax, [rsp + 400 - 8] // 584 + 400 - 8 == 976 ; rax = [976] <- WRONG
> 
> Instead the last instruction should be
> 
> mov rax, [rsp + 400 + 8] // 584 + 400 + 8 == 992 ; rax = [992]
> 

There are

      if (eax_live)
        {
          insn = emit_insn (gen_push (eax));
          allocate -= UNITS_PER_WORD;
...
      if (r10_live)
        {
          r10 = gen_rtx_REG (Pmode, R10_REG);
          insn = emit_insn (gen_push (r10));
          allocate -= UNITS_PER_WORD;
...
     if (r10_live && eax_live)
        {
          t = plus_constant (Pmode, stack_pointer_rtx, allocate);
          emit_move_insn (gen_rtx_REG (word_mode, R10_REG),
                          gen_frame_mem (word_mode, t));
          t = plus_constant (Pmode, stack_pointer_rtx,
                             allocate - UNITS_PER_WORD);
          emit_move_insn (gen_rtx_REG (word_mode, AX_REG),
                          gen_frame_mem (word_mode, t));
        }

They look OK to me.