X-Authentication-Warning:	acp3bf.physik.rwth-aachen.de: broeker owned process doing -bs
Date:	Tue, 29 Feb 2000 15:07:06 +0100 (MET)
From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
X-Sender:	broeker AT acp3bf
To:	djgpp-workers AT delorie DOT com
Subject:	Re: Debugging difficulties with GCC 2.95.2
In-Reply-To:	<38BBC78A.B416715E@inti.gov.ar>
Message-ID:	<Pine.LNX.4.10.10002291457460.10083-100000@acp3bf>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	dj-admin AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Tue, 29 Feb 2000, salvador wrote:

> BTW, I see a lot of crazy things using gdb 4.18 (from RHIDE) and gcc 2.95.1,
> like functions where the first steped line is at the end (small ones) so after
> steping a little more you go back! and then revisit the line! and was using
> -gstabs+3, so something is really broken.

This jumping back and forth, in and of itself, does not mean anything is
broken. During the optimization steps, the compiler may reorder statements
in a way that makes the debugger step back and forth in the source code.

This did not happen regularly in x86 code, before, but if you ever step
through highly optimized code on a RISC machine, or an Alpha CPU, you get
used to this behaviour. I think gcc-2.95 just optimizes things more
strongly than any of the predecessors, including aggressive reordering of
single instructions which may allow the CPU to carry out several
operations in parallel.

To really check this, there is no other way than to look at the assembly
source code generated by the compiler. You may want to use -fverbose-asm,
and maybe the -Wa,-alhs or similar swiches, to get a complete listing.

Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.

- Raw text -