From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111818 invoked by alias); 22 Nov 2015 05:09:06 -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 111791 invoked by uid 89); 22 Nov 2015 05:09:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 3 recipients X-HELO: bosmailout04.eigbox.net Received: from bosmailout04.eigbox.net (HELO bosmailout04.eigbox.net) (66.96.189.4) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Sun, 22 Nov 2015 05:09:02 +0000 Received: from bosmailscan01.eigbox.net ([10.20.15.1]) by bosmailout04.eigbox.net with esmtp (Exim) id 1a0MtY-0008QL-6d; Sun, 22 Nov 2015 00:09:00 -0500 Received: from [10.115.3.32] (helo=bosimpout12) by bosmailscan01.eigbox.net with esmtp (Exim) id 1a0MtY-00055f-2J; Sun, 22 Nov 2015 00:09:00 -0500 Received: from bosauthsmtp05.yourhostingaccount.com ([10.20.18.5]) by bosimpout12 with id kV8q1r00606Zqne01V8t21; Sun, 22 Nov 2015 00:09:00 -0500 X-Authority-Analysis: v=2.1 cv=Arlg3YNP c=1 sm=1 tr=0 a=eBvjjtMVdWwtQGedh7GyLg==:117 a=sZx1nW7oDdbgogxTPqu5Xw==:17 a=pq4jwCggAAAA:8 a=QPcu4mC3AAAA:8 a=C8F9KGFtAAAA:8 a=88b2x-oFWvEA:10 a=N659UExz7-8A:10 a=qtqOOiqGOCEA:10 a=PSY8qBEb5NelS-Y8N_cA:9 a=dqo5CDCoD1DlPrCC:21 a=n2YnaJnodKX_NmQt:21 a=pILNOxqGKmIA:10 Received: from [207.118.20.56] (port=50242 helo=[192.168.1.47]) by bosauthsmtp05.eigbox.net with esmtpa (Exim) id 1a0MtO-0003oe-E9; Sun, 22 Nov 2015 00:08:50 -0500 Subject: Re: basic asm and memory clobbers To: Sandra Loosemore References: <563FE459.3000003@LimeGreenSocks.com> <20151109093229.GA5260@gate.crashing.org> <56493010.9070707@LimeGreenSocks.com> <564A4AA5.1080706@redhat.com> <564AC155.4040601@LimeGreenSocks.com> <564B9CB1.1060001@redhat.com> <564E762B.6070705@LimeGreenSocks.com> <564E7D17.6010609@codesourcery.com> Cc: Jeff Law , Segher Boessenkool , "gcc@gcc.gnu.org" , rth@gcc.gnu.org, pinskia@gcc.gnu.org From: David Wohlferd Message-ID: <56514DCC.4050908@LimeGreenSocks.com> Date: Sun, 22 Nov 2015 05:09:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <564E7D17.6010609@codesourcery.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-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg00144.txt.bz2 On 11/19/2015 5:53 PM, Sandra Loosemore wrote: > On 11/19/2015 06:23 PM, David Wohlferd wrote: > >>> About the only immediate task would be to ensure that the >>> documentation for traditional asms clearly documents the desired >>> semantics and somehow note that there are known bugs in the >>> implementation (ie 24414, handling of flags registers, and probably >>> other oddities) >> >> Given that gcc is at phase 3, I'm guessing this work won't be in v6? Or >> would this be considered "general bugfixing?" >> >> The reason I ask is I want to clearly document what the current behavior >> is as well as informing them about what's coming. If this isn't >> changing until v7, the text can be updated then to reflect the new >> behavior. > > Documentation fixes are accepted all the way through Stage 4, since > there's less risk of introducing regressions in user programs from > accidental documentation mistakes than code errors. The code change isn't yet finalized. I'm hoping to doc something vaguely like: "basic asm (other than at top level) is being deprecated because potentially unsafe due to optimizations . You can locate the statements that will no longer be supported using -Wonly-top-basic-asm. Change them to use extended asm instead." What's your take on having the user guide link to the gcc wiki? If we do make this change, I'd kinda like to create a "how to convert basic asm to extended." But it doesn't seem like a good fit for the user docs. But if the user docs don't reference the wiki, I doubt anyone would ever find it. > OTOH, I'd discourage adding anything to the docs about anticipated > changes in future releases, except possibly to note that certain > features or behavior are deprecated and may be removed in future > releases (with a suggestion about what you should do instead). I'd love to see the doc folks make a pass and remove every "some day this won't work" text that doesn't include this. If there is no way for users to prepare, you aren't helping. And remove all the "some day there might be a new feature" stuff too. It just wastes users' time trying to figure out if "some day" has arrived yet. And it makes them cry when the new feature, which is exactly what they need, isn't there yet. > We've already got too many "maybe someday this will be fixed" notes in > the manual that are not terribly useful to users. You'd get my vote to remove them all. If I got a vote. dw