From:	Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: GCC 3.1 and DJGPP - observations.
Date:	4 Jun 2002 11:38:39 GMT
Organization:	Aachen University of Technology (RWTH)
Lines:	29
Message-ID:	<adi8rv$dtf$1@nets3.rz.RWTH-Aachen.DE>
References:	<3CFC9165 DOT 47E43C09 AT yahoo DOT com>
NNTP-Posting-Host:	acp3bf.physik.rwth-aachen.de
X-Trace:	nets3.rz.RWTH-Aachen.DE 1023190719 14255 137.226.32.75 (4 Jun 2002 11:38:39 GMT)
X-Complaints-To:	abuse AT rwth-aachen DOT de
NNTP-Posting-Date:	4 Jun 2002 11:38:39 GMT
Originator:	broeker@
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

CBFalconer <cbfalconer AT yahoo DOT com> wrote:

> 3) All versions were compiled with O2.  Looking at the generated
> code with "objdump -dS" it appears as if the optimization is quite
> different.  

It's supposed to be.  The new optimization engine is one of the major
new features advertised for GCC-3.x.  It would have been rather
un-interesting if it didn't effect the optimized code, wouldn't it?

> Many lumps seem to be relegated to "final" code outside the purvey
> of the source.

This might be a hint of suboptimal debug info generation, depending on
what those "lumps" are.  OTOH, you shouldn't interpret too much into
an objdump -dS, especially not into the C source lines listed with it.
Heavy optimization tends to mix up code from several source lines in
the machine instruction stream.  Looked the other way round, this
means that the code for a single line of code will be torn into
little, non-consecutive pieces.  objdump -S cannot reflect this
without blowing every sensible output size limit --- you'll have to
look at the line-number debug info statements to make sense of the
code.

> These are just observations.  None of them seem to be critical.

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

- Raw text -