From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6604 invoked by alias); 11 Apr 2010 16:02:15 -0000 Received: (qmail 6511 invoked by uid 22791); 11 Apr 2010 16:02:14 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 11 Apr 2010 16:02:10 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 0A5EA2BAB6D; Sun, 11 Apr 2010 12:02:09 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id hk40tDssB8lu; Sun, 11 Apr 2010 12:02:08 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id AE02F2BAB64; Sun, 11 Apr 2010 12:02:08 -0400 (EDT) Message-ID: <4BC1F277.6020804@adacore.com> Date: Sun, 11 Apr 2010 16:02:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Grigori Fursin CC: 'Duncan Sands' , 'Eric Botcazou' , gcc@gcc.gnu.org, 'Steven Bosscher' Subject: Re: dragonegg in FSF gcc? References: <20100409163655.GA25781@bromo.med.uc.edu> <4BC1D647.60902@free.fr> <201004111632.04289.ebotcazou@adacore.com> <4BC1EC78.4050808@free.fr> <003601cad98f$83546f60$89fd4e20$@com> In-Reply-To: <003601cad98f$83546f60$89fd4e20$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00196.txt.bz2 Grigori Fursin wrote: > Hello, > > Hope my question will not completely divert the topic of this discussion - > just curious what do you mean by better code? Better execution time, code size, > compilation time?.. Could mean all these things as well as other issues a) better realiability b) better behavior for undefined cases c) better source-object mapping for coverage/certification purposes d) better predictability e) better debugging information I am sure I could thing up many additions to this list if I spent more time :-) And of course there are many other quality issues for compilers that do not come under the "better code" category. Comparing compilers is not an easy thing to do :-) 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 Robert Dewar