From owner-freebsd-current Sat Feb 8 17:24:35 2003 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 206AF37B401 for ; Sat, 8 Feb 2003 17:24:34 -0800 (PST) Received: from stork.mail.pas.earthlink.net (stork.mail.pas.earthlink.net [207.217.120.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7703D43F75 for ; Sat, 8 Feb 2003 17:24:33 -0800 (PST) (envelope-from tlambert2@mindspring.com) Received: from pool0226.cvx40-bradley.dialup.earthlink.net ([216.244.42.226] helo=mindspring.com) by stork.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 18hgCt-0006Ko-00; Sat, 08 Feb 2003 17:24:32 -0800 Message-ID: <3E45AD75.47C80368@mindspring.com> Date: Sat, 08 Feb 2003 17:23:01 -0800 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Schultz Cc: Ray Kohler , freebsd-current@FreeBSD.ORG Subject: Re: Compiling with high optimization? References: <20030208173756.GA56030@arkadia.nv.cox.net> <20030208232724.GA20435@HAL9000.homeunix.com> <3E459BF3.BB3FC381@mindspring.com> <20030209002542.GA20812@HAL9000.homeunix.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a4574f64eb36913c47966288ebad833de1a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG David Schultz wrote: > Thus spake Terry Lambert : > > Actually, failure to use optimization suppresses some compilation > > warnings, particularly those which normally print from using some > > variables without initializing them. > > I think you're thinking of dataflow analysis, which I believe gcc > does with -O and higher optimization levels. So unless you're > using -O0, I would expect that you'd get all the warnings you > want. See the thread "Re: tmpfile breakage on setuid executables". Kris accidently introduced a bug that had to do with whether or not a variable was used before it was initialized. The compiler didn't complain when he checked it before committing it because optimization was off by default; it should have complained, e.g.: "x.c:9:warning: `foo' might be used uninitialized in this function" > > There are a number of places, particularly on non-i386 platforms, > > where optimization actually doesn't work. I think that's why it > > was turned off for the libc compilation, and why the bug crept in. > > > > It's probably useful to compile world with optimization occasionally, > > to make compilation-time detectable bugs like that to show up, but, as > > you point out, it'd probably be a *bad* idea to actually use the > > resulting code, at least until after the next GCC import, which will > > supposedly fix the Alpha optimizer. > > Yes, the possibility of being bitten by compiler bugs is certainly > higher with higher optimization levels. Alpha with -O2 seems to > have been broken for years, and I have seen strange things happen > on IA64 as well. But the i386 code generators have received much > wider testing and debugging, so there is somewhat less danger there. Yes. I just wanted to point out that what's probably a good idea for catching coding errors like uninitialized variables is definitely not a good idea for distributing code for people to run. I wasn't really sure why he was asking, so I tried to look at it from both angles. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message