From patchwork Mon Sep 27 08:58:37 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tristan Gingold X-Patchwork-Id: 65821 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 44C26B70D2 for ; Mon, 27 Sep 2010 18:58:48 +1000 (EST) Received: (qmail 25117 invoked by alias); 27 Sep 2010 08:58:46 -0000 Received: (qmail 25106 invoked by uid 22791); 27 Sep 2010 08:58:45 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (212.99.106.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 27 Sep 2010 08:58:40 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 4367DCB023E; Mon, 27 Sep 2010 10:58:38 +0200 (CEST) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4db2FWIMJmy; Mon, 27 Sep 2010 10:58:38 +0200 (CEST) Received: from ulanbator.act-europe.fr (ulanbator.act-europe.fr [10.10.1.67]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mel.act-europe.fr (Postfix) with ESMTP id 17532CB01D7; Mon, 27 Sep 2010 10:58:37 +0200 (CEST) From: Tristan Gingold Subject: [Patch] alpha: fix stack checking for alloca-ing a big chunk Date: Mon, 27 Sep 2010 10:58:37 +0200 Message-Id: Cc: Richard Henderson To: gcc-patches Patches Mime-Version: 1.0 (Apple Message framework v1081) 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 Hi, there is a flaw in the stack-probing loop of alpha.md:allocate_stack: the computation of 'want' may wrap-around 0 and therefore the loop will be skipped. This may happen if the amount to allocate is larger than the current address of the stack pointer. This condition happens several times in our Ada testsuite (on VMS, with images linked using /p0image). This patch proposes one solution to fix this issue: instead of comparing the first probe address with the future value of SP, it simply tests the amount of memory to be allocated. This is bullet-proof but needs one more instruction. An alternate solution would be to use GE instead of GEU as it is much less likely to wrap around 2**63 (given that no Alpha cpu implemented 64 bits of VA - AFAIK). We have such a patch for years and I sanity checked it on head. OK for mainline ? Tristan. 2010-09-27 Tristan Gingold * config/alpha/alpha.md: Change the initial condition of the probing loop. --- a/gcc/config/alpha/alpha.md +++ b/gcc/config/alpha/alpha.md @@ -6588,15 +6588,17 @@ emit_insn (gen_subdi3 (want, stack_pointer_rtx, force_reg (Pmode, operands[1]))); - emit_insn (gen_adddi3 (tmp, stack_pointer_rtx, GEN_INT (-4096))); if (!CONST_INT_P (operands[1])) { + rtx limit = GEN_INT (4096); out_label = gen_label_rtx (); - test = gen_rtx_GEU (VOIDmode, want, tmp); - emit_jump_insn (gen_cbranchdi4 (test, want, tmp, out_label)); + test = gen_rtx_LTU (VOIDmode, operands[1], limit); + emit_jump_insn + (gen_cbranchdi4 (test, operands[1], limit, out_label)); } + emit_insn (gen_adddi3 (tmp, stack_pointer_rtx, GEN_INT (-4096))); emit_label (loop_label); memref = gen_rtx_MEM (DImode, tmp); MEM_VOLATILE_P (memref) = 1;