From patchwork Fri Jun 22 18:10:55 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 166650 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 E8AAFB6EE7 for ; Sat, 23 Jun 2012 04:11:31 +1000 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1340993492; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:Received:In-Reply-To:References:Date: Message-ID:Subject:From:To:Cc:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=uZ2CE5BQ4Lhm5yw1Q22gMC+5gaU=; b=CYM5UsP174CjzeV A1cUFRdWYwAkblB8ZRYx/4R+G504aofe3qQug/dMe/B1wFhzbrjfCEBzInMAo4oI Lz33k58P/1ifDizBF+j5fqHDsJfKp4iAmIB0qZO6TlTp+6k+J0tb43fctRqWcYZg aZ5MC3Ui3G4Zr4IHP3lKYCQ77jHY= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=FTpca4aba9C6MMvUYir45VVlq1xNPyezWWwkyIkY0jemLBpiszPsb1ZckX9Wxi dYtGM8Oee9Juitrop7tFJsTGT/rnLhi6G1muK3tagGmqjyoQ82W5gyRkEU91R2Xk 6+wRRkKzdqYQzdOV41T76IzoZ4WbupByyYDzmHvd0e26c=; Received: (qmail 13863 invoked by alias); 22 Jun 2012 18:11:22 -0000 Received: (qmail 13847 invoked by uid 22791); 22 Jun 2012 18:11:20 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, KHOP_RCVD_TRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-qa0-f47.google.com (HELO mail-qa0-f47.google.com) (209.85.216.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 22 Jun 2012 18:10:56 +0000 Received: by qabg1 with SMTP id g1so506184qab.20 for ; Fri, 22 Jun 2012 11:10:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.135.10 with SMTP id l10mr1673688qct.6.1340388655576; Fri, 22 Jun 2012 11:10:55 -0700 (PDT) Received: by 10.229.192.129 with HTTP; Fri, 22 Jun 2012 11:10:55 -0700 (PDT) In-Reply-To: <20120622171126.GA6827@kam.mff.cuni.cz> References: <20120520144738.GA2225@intel.com> <20120622171126.GA6827@kam.mff.cuni.cz> Date: Fri, 22 Jun 2012 11:10:55 -0700 Message-ID: Subject: Re: PATCH: PR target/53383: Allow -mpreferred-stack-boundary=3 on x86-64 From: "H.J. Lu" To: Jan Hubicka Cc: Richard Henderson , "H. Peter Anvin" , gcc-patches@gcc.gnu.org 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 Fri, Jun 22, 2012 at 10:11 AM, Jan Hubicka wrote: >> >>> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi >> >>> index 4c5c79f..daa1f3a 100644 >> >>> --- a/gcc/doc/invoke.texi >> >>> +++ b/gcc/doc/invoke.texi >> >>> @@ -13521,6 +13521,12 @@ Attempt to keep the stack boundary aligned to a 2 raised to @var{num} >> >>>  byte boundary.  If @option{-mpreferred-stack-boundary} is not specified, >> >>>  the default is 4 (16 bytes or 128 bits). >> >>> >> >>> +@strong{Warning:} When generating code for the x86-64 architecture with >> >>> +SSE extensions disabled, @option{-mpreferred-stack-boundary=3} can be >> >>> +used to keep the stack boundary aligned to 8 byte boundary.  You must >> >>> +build all modules with @option{-mpreferred-stack-boundary=3}, including >> >>> +any libraries.  This includes the system libraries and startup modules. > > I would suggest to re-word this paragraph. > Perhaps something along lines > > x86-64 ABI require 16 byte stack alignment. It is possible to compile code with > -mpreferred-stack-boundary=3 where stack alignment is 8 bytes only.  This is > ABI incompatible and intended to be used in controlled environment where stack > space is important limitation. It may lead to wrong code when functions > compiled with 16 byte stack alignment (such as functions from a standard > library) are called with misaligned stack.  In this case the of SSE registers > may lead to misaligned memory access traps. In addition, va-arg will > incorrectly handle 16 byte aligned objects (including x87 long double and > __int128) leading to wrong results rather than traps. > > Fell free to fix my english and extend it.  I just want to make it sure > that the paragraph explains how things break (i.e. by calling something > with default stack alignment from function with 8byte alignment.) and that > it can break for non-SSE code, too, when using va-args on 16 byte aligned > objects. > > The patch is fine with this change.  Please also add change to news.html with > similar explanation. > Here is the patch for invoke.texi. OK to install? I will prepare a similar one for news.html. Thanks. diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index 029a7ab..87e0d1c 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -13579,9 +13579,18 @@ the default is 4 (16 bytes or 128 bits). @strong{Warning:} When generating code for the x86-64 architecture with SSE extensions disabled, @option{-mpreferred-stack-boundary=3} can be -used to keep the stack boundary aligned to 8 byte boundary. You must -build all modules with @option{-mpreferred-stack-boundary=3}, including -any libraries. This includes the system libraries and startup modules. +used to keep the stack boundary aligned to 8 byte boundary. Since +x86-64 ABI require 16 byte stack alignment, this is ABI incompatible and +intended to be used in controlled environment where stack space is +important limitation. This option will lead to wrong code when functions +compiled with 16 byte stack alignment (such as functions from a standard +library) are called with misaligned stack. In this case, SSE +instructions may lead to misaligned memory access traps. In addition, +variable arguments will be handled incorrectly for 16 byte aligned +objects (including x87 long double and __int128), leading to wrong +results. You must build all modules with +@option{-mpreferred-stack-boundary=3}, including any libraries. This +includes the system libraries and startup modules. @item -mincoming-stack-boundary=@var{num} @opindex mincoming-stack-boundary