From patchwork Thu Aug 5 18:30:10 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 61012 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id E7B31B6EED for ; Fri, 6 Aug 2010 04:30:20 +1000 (EST) Received: (qmail 8512 invoked by alias); 5 Aug 2010 18:30:17 -0000 Received: (qmail 8492 invoked by uid 22791); 5 Aug 2010 18:30:16 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, TW_XF X-Spam-Check-By: sourceware.org Received: from mail-pw0-f47.google.com (HELO mail-pw0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Aug 2010 18:30:12 +0000 Received: by pwj1 with SMTP id 1so222863pwj.20 for ; Thu, 05 Aug 2010 11:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.114.103.9 with SMTP id a9mr12787916wac.174.1281033010754; Thu, 05 Aug 2010 11:30:10 -0700 (PDT) Received: by 10.220.182.135 with HTTP; Thu, 5 Aug 2010 11:30:10 -0700 (PDT) In-Reply-To: <4C5B0273.9030907@twiddle.net> References: <1280879596-1089-1-git-send-email-rth@twiddle.net> <1280879596-1089-7-git-send-email-rth@twiddle.net> <4C5AD86F.3020206@twiddle.net> <4C5ADBA8.7050706@twiddle.net> <4C5AFE39.8090008@twiddle.net> <4C5B0273.9030907@twiddle.net> Date: Thu, 5 Aug 2010 11:30:10 -0700 Message-ID: Subject: Re: [PATCH 6/9] Emit the prologue/epilogue using frame offsets. From: "H.J. Lu" To: Richard Henderson Cc: gcc-patches@gcc.gnu.org, kai.tietz@onevision.com, ubizjak@gmail.com X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org On Thu, Aug 5, 2010 at 11:26 AM, Richard Henderson wrote: > On 08/05/2010 11:19 AM, H.J. Lu wrote: >> It is interesting. I saw it on 32bit host with 32bit HOST_WIDE_INT. Is it >> a signed vs. unsigned issue? stack_alignment_needed is unsigned. > > Yes, signed is the issue.  Previously we'd have > >  -stack_alignment_needed / 8 >  -256u / 8 >  0xffffff00u / 8 >  0x1fffffe0u > > If you receive a memory layout such that the stack is <= 0x1fffffff, > the program will happen to work.  With the cast we get -32 and not > a large unsigned number, which is what we really wanted. > I think this patch is clearer and also fixes the issue. diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index d809d44..ecccef1 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -8639,7 +8639,8 @@ ix86_emit_save_reg_using_mov (enum machine_mode mode, unsi gned int regno, reference to the locations within the frame. Instead, simply compute the location of the aligned frame from the frame pointer. */ - addr = GEN_INT (-crtl->stack_alignment_needed / BITS_PER_UNIT); + addr = GEN_INT (-(crtl->stack_alignment_needed + / BITS_PER_UNIT)); addr = gen_rtx_AND (Pmode, hard_frame_pointer_rtx, addr); addr = plus_constant (addr, -cfa_offset);