From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20653 invoked by alias); 12 Feb 2016 07:05:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 20611 invoked by uid 89); 12 Feb 2016 07:05:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=6th, feelings, long-time, Hx-languages-length:6313 X-HELO: bosmailout01.eigbox.net Received: from bosmailout01.eigbox.net (HELO bosmailout01.eigbox.net) (66.96.190.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 12 Feb 2016 07:05:43 +0000 Received: from bosmailscan06.eigbox.net ([10.20.15.6]) by bosmailout01.eigbox.net with esmtp (Exim) id 1aU7nQ-0002aG-Gv for gcc-patches@gcc.gnu.org; Fri, 12 Feb 2016 02:05:40 -0500 Received: from [10.115.3.32] (helo=bosimpout12) by bosmailscan06.eigbox.net with esmtp (Exim) id 1aU7nQ-00051r-FC for gcc-patches@gcc.gnu.org; Fri, 12 Feb 2016 02:05:40 -0500 Received: from bosauthsmtp10.yourhostingaccount.com ([10.20.18.10]) by bosimpout12 with id HK5d1s00C0D2CUy01K5gMX; Fri, 12 Feb 2016 02:05:40 -0500 X-Authority-Analysis: v=2.1 cv=HK1NF+dv c=1 sm=1 tr=0 a=Kpo39fPXdbgqDwiI3/AEUA==:117 a=sZx1nW7oDdbgogxTPqu5Xw==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=88b2x-oFWvEA:10 a=N659UExz7-8A:10 a=jFJIQSaiL_oA:10 a=mDV3o1hIAAAA:8 a=zqaJJmVNGiGdOtNkEBwA:9 a=pILNOxqGKmIA:10 Received: from [207.118.20.56] (port=50456 helo=[192.168.1.160]) by bosauthsmtp10.eigbox.net with esmtpa (Exim) id 1aU7nM-0007ZP-VD; Fri, 12 Feb 2016 02:05:37 -0500 Subject: Re: AW: Wonly-top-basic-asm To: Bernd Schmidt , Bernd Edlinger , "gcc-patches@gcc.gnu.org" , Richard Henderson , "jason@redhat.com" References: <56A54EF9.8060006@LimeGreenSocks.com> <56A61442.3090803@redhat.com> <56A9C134.1030500@LimeGreenSocks.com> <56B80F57.9020606@LimeGreenSocks.com> <56BBCC90.9020001@LimeGreenSocks.com> <56BCAB73.20506@redhat.com> Cc: "segher@kernel.crashing.org" , "sandra@codesourcery.com" , "Paul_Koning@Dell.com" , Jeff Law , "bernds_cb1@t-online.de" , Andrew Haley , David Wohlferd , Sandra Loosemore From: David Wohlferd Message-ID: <56BD8427.4050405@LimeGreenSocks.com> Date: Fri, 12 Feb 2016 07:05:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56BCAB73.20506@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-EN-UserInfo: 97390230d6758ac7ebdf93f8c6197d31:931c98230c6409dcc37fa7e93b490c27 X-EN-AuthUser: dw@limegreensocks.com X-EN-OrigIP: 207.118.20.56 X-EN-OrigHost: unknown X-SW-Source: 2016-02/txt/msg00834.txt.bz2 > I don't think this is a patch we're considering for gcc-6, at least > not for the initial release - I imagine it could be backported from > gcc-7 at some point. Actually, it was my intent that this apply to v6. It's not like there is a significant change here. We're documenting long-time behavior, and adding a (disabled) warning. The reasons I think this is needed for v6 are: 1) We have become aware of places where basic asm's existing behavior is a problem. This patch provides a way for users to locate these issues with a minimal, non-intrusive change. 2) There is a significant change to this behavior being proposed for v7. When this happens, having a way to locate affected statements with features from a stable release seems desirable. > Like the other Bernd I have a preference for just -Wbasic-asm. I'd > make the analogy with -Wparentheses - we don't warn about every > parenthesis, but the name of an option is not the place for detailed > explanations of how it works. Less typing and less to remember is > preferrable IMO. While I still prefer Wbasic-asm-in-function, I really don't have strong feelings here. Since both you and Bernd prefer this, I have changed it. >> + /* Warn on basic asm used inside of functions, >> + EXCEPT when in naked functions. Also allow asm (""). */ > > No all-caps. Fixed. >> @subsubheading Remarks >> -Using extended @code{asm} typically produces smaller, safer, and more >> +Using extended @code{asm} (@pxref{Extended Asm}) typically produces >> smaller, >> +safer, and more >> efficient code, and in most cases it is a better solution than basic > > Rewrap the paragraph? I could, but then people get cranky about how hard the patch is to review. >> -Here is an example of basic @code{asm} for i386: >> +Basic @code{asm} statements do not perform an implicit "memory" clobber >> +(@pxref{Clobbers}). Also, there is no implicit clobbering of >> @emph{any} >> +registers, so (other than in @code{naked} functions which follow the >> ABI >> +rules) changed registers must be restored to their original value >> before >> +exiting the @code{asm}. While this behavior has not always been >> +documented, GCC has worked this way since at least v2.95.3. >> >> +@strong{Warning:} This "clobber nothing" behavior may be different >> than how >> +other compilers treat basic @code{asm}, since the C standards for the >> +@code{asm} statement provide no guidance regarding these semantics. >> As a >> +result, @code{asm} statements that work correctly on other compilers >> may not >> +work correctly with GCC (and vice versa), even though they both compile >> +without error. >> + >> +Future versions of GCC may change basic @code{asm} to clobber memory >> and >> +perhaps some (or all) registers. This change may fix subtle >> problems with >> +existing @code{asm} statements. However it may break or slow down ones >> +that were working correctly. To ``future-proof'' your asm against >> possible >> +changes to basic @code{asm}'s semantics, use extended @code{asm}. >> + >> +You can use @option{-Wbasic-asm-in-function} to locate basic @code{asm} >> +statements that may need changes, and refer to >> +@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to >> convert >> +from basic asm to extended asm} for information about how to perform >> the >> +conversion. > > I still think this is too verbose and would serve to confuse rather > than enlighten in practice. (If anyone feels otherwise, feel free to > overrule me.) I assume you mean someone besides me... > I'm also no longer sure about references to the wiki. This is not the first reference to the gcc wiki in the docs (looks like the 6th for gcc, plus 10 for other wikis). > Let's look at this existing paragraph from the manual: > > Since GCC does not parse the @var{AssemblerInstructions}, it has > no visibility of any symbols it references. This may result in GCC > discarding those symbols as unreferenced. > > I think extending this would be better. Something like > > "Since the C standards does not specify semantics for @code{asm}, it > is a potential source of incompatibilities between compilers. GCC does > not parse the @var{AssemblerInstructions}, which means there is no way > to communicate to the compiler what is happening inside them. GCC has > no visibility of any symbols referenced in the @code{asm} and may > discard them as unreferenced. It also does not know about side effects > that may occur, such as modifications of memory locations or > registers. GCC assumes that no such side effects occur, which may not > be what the user expected if code was written for other compilers. > > Since basic @code{asm} cannot easily be used in a reliable way, > @option{-Wbasic-asm} should be used to warn about the use of basic asm > inside a function. See > @uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to > convert from basic asm to extended asm} for information about how to > convert code to use extended @code{asm}." Hmm. Yes, that's better. But there are some things that got lost here that I think are important. How about: ------------ @strong{Warning:} The C standards do not specify semantics for @code{asm}, making it a potential source of incompatibilities between compilers. @code{asm} statements that work correctly on other compilers may not work correctly with GCC (and vice versa), even though both compile without error. GCC does not parse basic @code{asm}'s @var{AssemblerInstructions}, which means there is no way to communicate to the compiler what is happening inside them. GCC has no visibility of symbols in the @code{asm} and may discard them as unreferenced. It also does not know about side effects of the assembler code, such as modifications to memory or registers. Unlike some compilers, GCC assumes that no changes to either memory or registers occur. This assumption may change in a future release. To avoid complications from future changes to the semantics and the compatibility issues between compilers, use @option{-Wbasic-asm} to warn about the use of basic asm inside a function. See @uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to convert from basic asm to extended asm} for information about how to convert code to use extended @code{asm}. ------------ dw