From patchwork Wed Feb 6 10:16:30 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Botcazou X-Patchwork-Id: 1037419 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-495368-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="l3bxtusL"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 43vcmr10Vmz9sMl for ; Wed, 6 Feb 2019 21:16:43 +1100 (AEDT) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; q=dns; s=default; b=ngNoDhw21kCVE44s lreCAC3MNt91fY15N9c8fZduG45lhapfz1VIOqCBMugQ5/UrY97z7jEkfk0AoZAU /LGTjVfBxxW798cBG9fFxZ4vv8JTGAOv0SgGhyDq5QlXYYQFhS5CQkXAGNGjC+xM wpdIV4b2YJvqWmMy0SHqGwMPyIo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :to:subject:date:message-id:mime-version:content-type :content-transfer-encoding; s=default; bh=CEBOJUT2mTXoG/+il/NzqO /VIgc=; b=l3bxtusLqoPtW7cTILLR6crVwfB0JBCHC8KujXEUV9ZKMzezyROkNK TGDW130iPeZbrkfgQ8DMv1pU2FAU8Ov89FAJPPp6zRGJFdKmsyBVM8jS2oQ7rnp5 b2XaAkj+/BN9mAgY2M0E7hC+kzILBcZfYRofTzMES2wMMxlVCqWlg= Received: (qmail 70891 invoked by alias); 6 Feb 2019 10:16:37 -0000 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 Received: (qmail 70879 invoked by uid 89); 6 Feb 2019 10:16:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Feb 2019 10:16:35 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id BD68E80004 for ; Wed, 6 Feb 2019 11:16:32 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-QAYgv4vND4 for ; Wed, 6 Feb 2019 11:16:32 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 69B4E8137C for ; Wed, 6 Feb 2019 11:16:32 +0100 (CET) From: Eric Botcazou To: gcc-patches@gcc.gnu.org Subject: [i386] Fix wrong argument value on Windows Date: Wed, 06 Feb 2019 11:16:30 +0100 Message-ID: <1728770.F5DofJc6GO@polaris> MIME-Version: 1.0 Hi, this is a regression present on all active branches: if you compile the attached Ada testcase with -O2 -gnatp -fno-omit-frame-pointer for 32-bit Windows, you'll see that the compiler swaps a load based on the stack pointer with a store based on the frame pointer, thus clobbering a saved argument: pushl %ebp movl %esp, %ebp pushl %esi pushl %ebx pushl %eax <- %eax save movl $4108, %eax call ___chkstk_ms leal 8(%ebp), %esi subl %eax, %esp movl 8(%ebp), %ebx movl %edx, -20(%ebp) movl %esi, -12(%ebp) <- fp-based store movl (%esp,%eax), %eax <- sp-based load ... wrong value in eax... The load and the store are swapped because there are not based on the same register and the offset between them is seen as variable. The proposed fix is to add a memory blockage, like in other frame-related constructs. Tested on x86/Windows and x86-64/Windows, OK for all active branches? 2019-02-06 Eric Botcazou * config/i386/i386.c (ix86_expand_prologue): Generate a memory blockage after restoring registers saved to allocate the frame on Windows. 2019-02-06 Eric Botcazou * gnat.dg/opt76.adb: New test. Index: config/i386/i386.c =================================================================== --- config/i386/i386.c (revision 268508) +++ config/i386/i386.c (working copy) @@ -13579,8 +13579,9 @@ ix86_expand_prologue (void) } m->fs.sp_offset += allocate; - /* Use stack_pointer_rtx for relative addressing so that code - works for realigned stack, too. */ + /* Use stack_pointer_rtx for relative addressing so that code works for + realigned stack. But this means that we need a blockage to prevent + stores based on the frame pointer from being scheduled before. */ if (r10_live && eax_live) { t = gen_rtx_PLUS (Pmode, stack_pointer_rtx, eax); @@ -13589,6 +13590,7 @@ ix86_expand_prologue (void) t = plus_constant (Pmode, t, UNITS_PER_WORD); emit_move_insn (gen_rtx_REG (word_mode, AX_REG), gen_frame_mem (word_mode, t)); + emit_insn (gen_memory_blockage ()); } else if (eax_live || r10_live) { @@ -13596,6 +13598,7 @@ ix86_expand_prologue (void) emit_move_insn (gen_rtx_REG (word_mode, (eax_live ? AX_REG : R10_REG)), gen_frame_mem (word_mode, t)); + emit_insn (gen_memory_blockage ()); } } gcc_assert (m->fs.sp_offset == frame.stack_pointer_offset);