X-Authentication-Warning: delorie.com: mailnull set sender to djgpp-bounces using -f
Date: Sun, 24 Mar 2002 17:54:34 +0200
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: djgpp AT delorie DOT com
Message-Id: <9427-Sun24Mar2002175433+0200-eliz@is.elta.co.il>
X-Mailer: emacs 21.2.50 (via feedmail 8 I) and Blat ver 1.8.9
In-reply-to: <3C9DB84E.5ED3B308@yahoo.com> (message from CBFalconer on Sun, 24
	Mar 2002 12:38:22 GMT)
Subject: Re: Breakpoints crazy?
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1020324083735 DOT 4102H-100000 AT is> <3C9DB84E DOT 5ED3B308 AT yahoo DOT com>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> From: CBFalconer <cbfalconer AT yahoo DOT com>
> Newsgroups: comp.os.msdos.djgpp
> Date: Sun, 24 Mar 2002 12:38:22 GMT
> > 
> > It's IMHO a bad idea to turn off optimizations when debugging a program.
> > Compilers these days do such complicated code changes when optimizing
> > that you are effectively debugging a very different program.  So you
> > either need to debug the program twice, first without optimizations, then
> > with them (and who has the will power and resources to do that?), or use
> > untested program when you turn on optimizations for production version.
> 
> True enough, but you are usually debugging your own logical errors
> rather than performance issues (or compiler optimizer bugs).

The effect of a bug can be very different with and without
optimizations.  For example, uninitialized variables are known to
produce different effects depending on memory or register contents, so
they might well go unnoticed in an unoptimized program, but then raise
their ugly head in the production version.

Functions that are inlined by the compiler are another similar case:
the inlined code is typically less safe than a library function (it
trades safety for speed).

> With me such step by step debugging is a last resort anyhow.  A
> mild sprinkling of asserts and printfs is usually much more
> productive.

There are bugs that cannot be practically found with printf debugging.
One example is code that overwrites random locations.  You need
something like watchpoints with those bugs.

Also, inserting printf's might disable some optimizations (although
not as much as omitting the optimization switches altogether), and you
again get a different program.

> At any rate I think we are agreed that the OP has been confused by
> the optimization.

Sure.