Date: Mon, 21 Oct 2002 13:43:15 -0400 From: "Charles Swiger" <cswiger@mac.com> To: <stable@FreeBSD.ORG> Subject: GCC options, was: Re: 4.7-RELEASE crash [file system] Message-ID: <006501c27929$67cf3cd0$0301a8c0@prime> References: <20021019130404.A25131-100000@edge.foundation.invalid> <001901c27798$d033df70$0301a8c0@prime> <3DB2399F.3060900@zbzoom.net> <003a01c27849$6367d4d0$0301a8c0@prime> <20021021161902.GA396@HAL9000.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
David Schultz wrote: > Thus spake Charles Swiger <cswiger@mac.com>: >> PS: Arguably, people should be building with "-g -O" all of the >> time, even in production. GCC tends to generate the most reliable >> code for that combination of options, as those are exercised the >> most frequently. > > GCC specifically does *not* generate code that is any more or less > reliable when you use -g. The GCC folks are fairly picky about > that rule. The GCC team wants the compiler to produce reliable code under all circumstances, most likely. What the compiler actually does may not correspond perfectly to that intention. > As for optimization, I've never been bitten by any bugs in either -O0 or -O, > but in theory -O0 would save you from any bugs in the optimizer. -O0 means to disable the optimizer, agreed. However, the optimizer isn't a single thing; it's an entire range of individual optimization techniques. Different -O levels (-O0, -O, -O2, etc...) enable different combinations. Using -g may change some of the optimizations, such as disabling "-fomit-frame-pointer", if they are incompatible with symbolic debugging. It also has other implications on certain platforms, such as the HP/PA RISC and probably the SPARC, as those platforms tend to pass arguments in registers rather than putting them on the stack-- although the _space_ in the stack frame is reserved, but the contents may not be written there. On such platforms, -g tells the compiler to emit code to always write the arguments to the stack, which is useful when debugging. On the HP, that means that even leaf procedures need to allocate a stack frame rather than the callee using their caller's frame. (HP uses twisted calling conventions.) On the SPARC, that probably means something like a call FLUSHW, to flush the "register windows" used by that CPU architecture. -Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?006501c27929$67cf3cd0$0301a8c0>