From owner-freebsd-alpha Thu Mar 23 0:19:20 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.bayarea.net [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 3CE4137BDE4; Thu, 23 Mar 2000 00:19:09 -0800 (PST) (envelope-from edhall@screech.weirdnoise.com) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.9.3/8.9.3) with ESMTP id AAA12969; Thu, 23 Mar 2000 00:20:06 -0800 Message-Id: <200003230820.AAA12969@screech.weirdnoise.com> X-Mailer: exmh version 2.0.2 To: Andrew Gallatin Cc: obrien@FreeBSD.ORG, Howard Leadmon , freebsd-alpha@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, edhall@screech.weirdnoise.com Subject: Re: Compiler problems with -O2 (was Re: CVS Trouble, even under 4.0-RELEASE (alpha) HELP!) In-Reply-To: Message from Andrew Gallatin of "Wed, 22 Mar 2000 17:42:03 EST." <14553.19348.115781.273817@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 23 Mar 2000 00:20:06 -0800 From: Ed Hall Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Andrew Gallatin writes: : I take it the O2 bugs are not unique to us, but rather they are : generic across all OSes that gcc version 2.95.2 runs on? Do the gcc : people know these problems exist? Just FYI, the Linux kernel is compiled with: -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -mno-fp-regs \ -ffixed-8 -fno-strict-aliasing on Alpha, and seems quite stable with these flags. Yes, this is with GCC 2.95.2. On applications, I've seen gains of about 20% for the higher levels of optimization (for example, CSound processes a particular piece in 79 seconds when compiled with just -O, and 65 seconds with -O2). This is a useful improvement, though one that has to be balanced with the risks. I'm frankly astonished that it has been suggested that higher optimizations be disabled. Blindly compiling the world at -O2 may be folly, but using optimization can be quite useful for selected applications. The EGCS (now GCC) group does respond to bug reports, but they are to be forgiven if they give priority to "C code fragment X yields invalid assembler code Y" over "application Z is somehow broken by option W" reports. Like many free software projects (and some not-so-free ones) GCC has a limited number of developers capable of correcting its ills, so I'm sure some extra legwork on our part will increase the chance that issues will be addressed. I'm no stranger to optimizer bugs. But as often as not, the code I've seen fail under optimization is bad code. Optimization moves locals from the stack into registers (and vice-versa), reorders and removes redundant loads and stores, and does other things that cause bugs to surface. This is why it is a good idea to track down, if possible, the actual cause of the failure. -Ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message