From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4390 invoked by alias); 14 Dec 2015 18:57:31 -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 4276 invoked by uid 89); 14 Dec 2015 18:57:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: paperclip.tbsaunde.org Received: from tbsaunde.org (HELO paperclip.tbsaunde.org) (66.228.47.254) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 14 Dec 2015 18:57:28 +0000 Received: from tsaunders-iceball.corp.tor1.mozilla.com (unknown [IPv6:2607:f0c8:8000:80e0:3e97:eff:fec1:f2b4]) by paperclip.tbsaunde.org (Postfix) with ESMTPSA id D97C6C06B; Mon, 14 Dec 2015 18:57:26 +0000 (UTC) Date: Mon, 14 Dec 2015 18:57:00 -0000 From: Trevor Saunders To: Markus Trippelsdorf Cc: Richard Biener , Andi Kleen , Gerald Pfeifer , GCC Patches Subject: Re: [PATCH] doc: discourage use of __attribute__((optimize())) in production code Message-ID: <20151214185702.GB16122@tsaunders-iceball.corp.tor1.mozilla.com> References: <20151213081911.GA320@x4> <87mvtet8t6.fsf@tassilo.jf.intel.com> <20151214161453.GA16122@tsaunders-iceball.corp.tor1.mozilla.com> <20151214164057.GD1409@x4> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20151214164057.GD1409@x4> User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-12/txt/msg01427.txt.bz2 On Mon, Dec 14, 2015 at 05:40:57PM +0100, Markus Trippelsdorf wrote: > On 2015.12.14 at 11:20 -0500, Trevor Saunders wrote: > > On Mon, Dec 14, 2015 at 10:01:27AM +0100, Richard Biener wrote: > > > On Sun, Dec 13, 2015 at 9:03 PM, Andi Kleen wrote: > > > > Markus Trippelsdorf writes: > > > > > > > >> Many developers are still using __attribute__((optimize())) in > > > >> production code, although it quite broken. > > > > > > > > Wo reads documentation? @) If you want to discourage it better warn once > > > > at runtime. > > > > > > We're also quite heavily using it in LTO internally now. > > > > besides that does this really make sense? I suspect very few people are > > using this for the fun of it. I'd guess most usage is to disable > > optimizations to work around bugs, or maybe trying to get a very hot > > function optimized more. Either way I suspect its only used by people > > with good reason and this would just really iritate them. > > Well, if you look at bugzilla you'll find several wrong code bugs caused > by this attribute, e.g.: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59262 is that wrong code? it looks to me like somebody thinks its missed optimization, and personally I'd say its not a bug just not fully expected behavior. > Also Richi stated in the past (I quote): > »I consider the optimize attribute code seriously broken and > unmaintained (but sometimes useful for debugging - and only that).« > > https://gcc.gnu.org/ml/gcc/2012-07/msg00201.html I'm certainly not recommending its use, and noting in docs that its results can be suprising seems reasonable, but runtime warnings seems likely to annoy users. Trev > > -- > Markus