From patchwork Wed Aug 15 15:41:36 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Iain Sandoe X-Patchwork-Id: 957970 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-483711-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=sandoe.co.uk Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="OLmGbsJU"; 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 41rDGn6rrFz9sCP for ; Thu, 16 Aug 2018 01:41:52 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:from :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; q=dns; s=default; b=tQB0LxIMpjrJzz7afi1H yl4nbAyBqAnuf6/GMpNUWYgDua5d4aUJatdu8IBPdrcfte6iJdxdHOfFB2hWmyBj xtTHYy5WuWeOsDUQO9+/pdjWfYKIchRxG/BCCEs45SeZrZoWVdFwk7ipw+K6o11k yCwWNh4Sxl7QMwsUE9UQHqE= 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 :content-type:content-transfer-encoding:mime-version:subject :message-id:date:cc:to; s=default; bh=dT7BFor3L++ofieatBFgM9fCBc o=; b=OLmGbsJUqhJYj+oO9l0OaNF5XNwZ7JEzDgCI/Vq8CFg15V51OwgT6b4DXj 1IX7lCWer5hBKyzRmYA+Hkgs10NZTSYZorU+89+sTYmOOKnS619qOg8DCBcJk5p3 LBrsx9LLnWna1jGHturDZIHOp3oAwBg8ELdn02O0PV9ZZ0Wsw= Received: (qmail 42232 invoked by alias); 15 Aug 2018 15:41:45 -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 42222 invoked by uid 89); 15 Aug 2018 15:41:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.1 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_COUK, KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=mandates, variants, Hx-spam-relays-external:ESMTPA X-HELO: smtp2.wavenetuk.net Received: from lisa.wavenetuk.net (HELO smtp2.wavenetuk.net) (195.26.37.17) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Aug 2018 15:41:42 +0000 Received: from euterpe-sie.home (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp2.wavenetuk.net (Postfix) with ESMTPA id E6BF76001C0; Wed, 15 Aug 2018 16:41:39 +0100 (BST) From: Iain Sandoe Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Stack alignment on Darwin (PR78444) Message-Id: Date: Wed, 15 Aug 2018 16:41:36 +0100 Cc: Mike Stump To: GCC Patches , hjl.tools@gmail.com, Uros Bizjak Hi HJ, I am trying to track down a misalignment of the stack on Darwin (pr78444). In r163971 you applied this: --- gcc/config/i386/darwin.h (revision 163970) +++ gcc/config/i386/darwin.h (revision 163971) @@ -79,7 +79,9 @@ Failure to ensure this will lead to a crash in the system libraries or dynamic loader. */ #undef STACK_BOUNDARY -#define STACK_BOUNDARY 128 +#define STACK_BOUNDARY \ + ((profile_flag || (TARGET_64BIT && ix86_abi == MS_ABI)) \ + ? 128 : BITS_PER_WORD) #undef MAIN_STACK_BOUNDARY #define MAIN_STACK_BOUNDARY 128 @@ -91,7 +93,7 @@ it's below the minimum. */ #undef PREFERRED_STACK_BOUNDARY #define PREFERRED_STACK_BOUNDARY \ - MAX (STACK_BOUNDARY, ix86_preferred_stack_boundary) + MAX (128, ix86_preferred_stack_boundary === I realise it’s a long time ago … .. but, have you any pointer to the reasoning here or what problem was being solved? (perhaps mail list discussion?) === Darwin’s 32b ABI mandates 128b alignment at functions calls: "The function calling conventions used in the IA-32 environment are the same as those used in the System V IA-32 ABI, with the following exceptions: ■ Different rules for returning structures ■ The stack is 16-byte aligned at the point of function calls “ Darwin’s 64b ABI refers directly to the SysV document, which also mandates [section 3.2.2] 128b (or 256b when __m256 is passed). === The following patch resolves pr78444 - but it’s not clear if it’s a correct fix - or we should be looking for an alternate solution to whatever r193671 was intending to achieve. thanks, Iain [PATCH] Fix for PR78444. maybe. --- gcc/config/i386/i386.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c index 163682bdff..405bfd082b 100644 --- a/gcc/config/i386/i386.c +++ b/gcc/config/i386/i386.c @@ -11530,6 +11530,15 @@ ix86_compute_frame_layout (void) crtl->preferred_stack_boundary = 128; crtl->stack_alignment_needed = 128; } + else if (TARGET_MACHO && crtl->preferred_stack_boundary < 128 + && !crtl->is_leaf) + { + /* Darwin's ABI specifies 128b alignment for both 32 and + 64 bit variants at call sites. So we apply this if the + current function is not a leaf. */ + crtl->preferred_stack_boundary = 128; + crtl->stack_alignment_needed = 128; + } stack_alignment_needed = crtl->stack_alignment_needed / BITS_PER_UNIT; preferred_alignment = crtl->preferred_stack_boundary / BITS_PER_UNIT;