From: Hans-Bernhard Broeker Newsgroups: comp.os.msdos.djgpp Subject: Re: preprpcessor for overiding gcc optimation switch Date: 20 Jun 2000 12:27:19 GMT Organization: Aachen University of Technology (RWTH) Lines: 23 Distribution: world Message-ID: <8innv7$i6j$1@nets3.rz.RWTH-Aachen.DE> References: <83zop3o170 DOT fsf AT mercury DOT bitbucket> <25c58271 DOT fc969396 AT usw-ex0104-033 DOT remarq DOT com> NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de X-Trace: nets3.rz.RWTH-Aachen.DE 961504039 18643 137.226.32.75 (20 Jun 2000 12:27:19 GMT) X-Complaints-To: abuse AT rwth-aachen DOT de NNTP-Posting-Date: 20 Jun 2000 12:27:19 GMT Originator: broeker@ To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Damian Yerrick wrote: > There is generally one main reason to turn off optimization in GCC: > when debugging your executable in GDB. Optimization rearranges > instructions to better fit in a Pentium's pipeline; this throws GDB > off balance. Not really true. It's actually one of the major advantages of GCC/GDB over some of the old system vendors' compilers/debuggers they were originally meant to replace that you *can* debug even a fully optimized program. Debugging can become harder, and there may be surprises, sure: variables may have been optimized away by GCC, so their contents can't be printed in gdb. Execution flow may jump back and forth across several lines of source code. Short function may get inlined away, so you can't set a breakpoint to them, any more. But nothing of that means you *can't* debug an optimized program. You just have to live with some drawbacks. -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.