From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98658 invoked by alias); 16 Nov 2015 21:29:14 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 98634 invoked by uid 89); 16 Nov 2015 21:29:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 3 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 16 Nov 2015 21:29:12 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 60EBE14CAA4; Mon, 16 Nov 2015 21:29:11 +0000 (UTC) Received: from localhost.localdomain (ovpn-113-72.phx2.redhat.com [10.3.113.72]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAGLTAEX003527; Mon, 16 Nov 2015 16:29:10 -0500 Subject: Re: basic asm and memory clobbers To: David Wohlferd , Segher Boessenkool References: <563FE459.3000003@LimeGreenSocks.com> <20151109093229.GA5260@gate.crashing.org> <56493010.9070707@LimeGreenSocks.com> Cc: "gcc@gcc.gnu.org" , rth@gcc.gnu.org, pinskia@gcc.gnu.org, Sandra Loosemore From: Jeff Law Message-ID: <564A4AA5.1080706@redhat.com> Date: Mon, 16 Nov 2015 21:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <56493010.9070707@LimeGreenSocks.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00081.txt.bz2 On 11/15/2015 06:23 PM, David Wohlferd wrote: > On 11/9/2015 1:32 AM, Segher Boessenkool wrote: >> On Sun, Nov 08, 2015 at 04:10:01PM -0800, David Wohlferd wrote: >>> It seems like a doc update is what is needed to close PR24414 (Old-style >>> asms don't clobber memory). >> What is needed to close the bug is to make the compiler work properly. > > The question of course is, what does 'properly' mean? My assertion is > that 10 years on, 'properly' means whatever it's doing now. Changing it > at this point will probably break more than it fixes, and (as you said) > there is a plausible work-around using extended asm. > > So while this bug could be resolved as 'invalid' (since the compiler is > behaving 'properly'), I'm thinking to split the difference and 'fix' it > with a doc patch that describes the supported behavior. I'd disagree. A traditional asm has to be considered an opaque blob that read/write/clobber any register or memory location. It's also the case that assuming an old style asm can read or clobber any memory location is the safe, conservative thing to do. So the right thing in my mind is to ensure that behaviour and document it. Andrew's logic is just plain wrong in that BZ. > >> Whether that means clobbering memory or not, I don't much care -- with >> the status quo, if you want your asm to clobber memory you have to use >> extended asm; if basic asm is made to clobber memory, if you want your >> asm to *not* clobber memory you have to use extended asm (which you >> can with no operands by writing e.g. asm("bork" : ); ). So both >> behaviours are available whether we make a change or not. >> >> But changing things now will likely break user code. Having an traditional asm clobber memory should not break user code. It may pessimize it slightly, but if it does, that code was already broken. >> (dot space space). >> >>> +Basic @code{asm} statements are not treated as though they used a >>> "memory" >>> +clobber, although they do implicitly perform a clobber of the flags >>> +(@pxref{Clobbers}). >> They do not clobber the flags. Observe: > > Ouch. i386 shows the same thing for basic asm. Sadly, I suspect this isn't consistent across targets. Jeff