From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7386 invoked by alias); 25 Jul 2005 22:50:13 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 7377 invoked by uid 22791); 25 Jul 2005 22:50:10 -0000 Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 25 Jul 2005 22:50:10 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 6EFE548CDC9; Mon, 25 Jul 2005 18:50:08 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 14667-01-2; Mon, 25 Jul 2005 18:50:08 -0400 (EDT) Received: from [127.0.0.1] (taconic.gnat.com [205.232.38.103]) by nile.gnat.com (Postfix) with ESMTP id 40F4D48CDC5; Mon, 25 Jul 2005 18:50:08 -0400 (EDT) Message-ID: <42E56C9E.6050800@adacore.com> Date: Mon, 25 Jul 2005 22:50:00 -0000 From: Robert Dewar User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) MIME-Version: 1.0 To: Louis LeBlanc CC: Giovanni Bajo , gcc@gcc.gnu.org Subject: Re: gcc 3.3.6 - stack corruption questions References: <20050725145524.GB71939@keyslapper.net> <036401c5912b$b8d51240$bf03030a@trilan> <20050725215959.GL71939@keyslapper.net> In-Reply-To: <20050725215959.GL71939@keyslapper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-07/txt/msg01079.txt.bz2 Louis LeBlanc wrote: > I would have expected much different results. Shouldn't the file > sizes be smaller (at least a little) with the -O3 switch? Maybe > there's a loop unrolled to make it faster, resulting in a larger > codebase? you generally expect -O3 files to be larger. inlining does not save space. Indeed in the context of Ada, where well thought out inlining is acheived by -O2 -gnatn (and the use of pragma Inline), we often see -O3 executables being not only larger but slower, presumably due to increased icache pressure. > The unoptimized version completed a 401,900 transaction test with no > problem. All day, I've been playing with different things, there are many bugs, most notably uninitialed vars, that show up only when you turn on optimization.