Date: Thu, 23 Mar 2000 00:20:06 -0800 From: Ed Hall <edhall@screech.weirdnoise.com> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: obrien@FreeBSD.ORG, Howard Leadmon <howardl@account.abs.net>, 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!) Message-ID: <200003230820.AAA12969@screech.weirdnoise.com> In-Reply-To: Message from Andrew Gallatin <gallatin@cs.duke.edu> of "Wed, 22 Mar 2000 17:42:03 EST." <14553.19348.115781.273817@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200003230820.AAA12969>