From: Hans-Bernhard Broeker 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: 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 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.