From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12717 invoked by alias); 11 Apr 2010 17:49:42 -0000 Received: (qmail 12709 invoked by uid 22791); 11 Apr 2010 17:49:42 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from one.firstfloor.org (HELO one.firstfloor.org) (213.235.205.2) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Apr 2010 17:49:36 +0000 Received: from basil.firstfloor.org (p5B3CA473.dip0.t-ipconnect.de [91.60.164.115]) by one.firstfloor.org (Postfix) with ESMTP id E46EA1AA0001; Sun, 11 Apr 2010 19:49:30 +0200 (CEST) Received: by basil.firstfloor.org (Postfix, from userid 1000) id 374D2B1A0A; Sun, 11 Apr 2010 19:49:30 +0200 (CEST) To: Robert Dewar Cc: Grigori Fursin , 'Duncan Sands' , 'Eric Botcazou' , gcc@gcc.gnu.org, 'Steven Bosscher' Subject: Re: dragonegg in FSF gcc? From: Andi Kleen References: <20100409163655.GA25781@bromo.med.uc.edu> <4BC1D647.60902@free.fr> <201004111632.04289.ebotcazou@adacore.com> <4BC1EC78.4050808@free.fr> <003601cad98f$83546f60$89fd4e20$@com> <4BC1F277.6020804@adacore.com> Date: Sun, 11 Apr 2010 18:15:00 -0000 In-Reply-To: <4BC1F277.6020804@adacore.com> (Robert Dewar's message of "Sun, 11 Apr 2010 12:01:59 -0400") Message-ID: <87ljctc21h.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 X-SW-Source: 2010-04/txt/msg00209.txt.bz2 Robert Dewar writes: > > Sure you can run some benchmarks and look for missed optimization > opportunities, that's always worth while, for instance people > regularly compare gcc and icc to look for cases where the gcc > optimization can be improved OT, but there's lots of cool data on all of this on http://embed.cs.utah.edu/embarrassing/dec_09/ I spent some time some time ago to file a few "missed optimizations" bugzillas based on examples there and some got addressed. I'm sure there are lots more nuggets in there (as in easy cases to improve gcc), but analyzing each example takes time. The reason each sample takes time to analyze is that it is sometimes a bug in the other compiler or different target options or so. Sometimes it's also undefined code. Yes there are plenty of bugs in there, but I didn't find any for gcc at least (but only looked at a relatively limited set) -Andi -- ak@linux.intel.com -- Speaking for myself only.