Comments in assember output

[Fabian Cenedese]

At 16:33 01.12.2006 -0500, John Yates wrote:
>On Friday 2006-12-01 Fabian Cenedese wrote:
>
>>                                           ... But when I tried it
>> it didn't mix the lines, I just got (almost) all lines from the cpp
>> source file and after that the assembler code.
>
>I have seen this effect quite regularly.  I do not know this for a
>fact but have always assumed that the incorporation of source code
>into the assembly listing was a classic stream merge based on line
>numbers.  This works okay as long as the generated code closely
>parallels the source.  It also depends on what bits of intermediate
>representation are allowed to claim source line correspondence.
>
>The reason that I suggest this explanation is that the gcc behavior
>seems very reminiscent of what I used to see for a while from the Apollo
>compilers.  A classic example was an assignment within a loop with an
>invariant RHS.  If the RHS required any expression evaluation and if
>the instructions carrying out that evaluation was moved out of the
>loop then all loop source lines up to and including that assignment
>would be emitted ahead of the loop in the vicinity of the RHS evaluation.

I don't know about that so I can't comment on it.

But I now tried with gcc 4.0 and I got much better results.

gcc (GCC) 4.1.0
GNU assembler 2.16.1

This gives the almost whole cpp/whole asm blocks.

gcc (GCC) 4.0.2
GNU assembler 2.16.1

This mixes asm and cpp much as expected:
 152:N:/src/CTaskTemplateClass.cpp ****                 Sleep(1);
 543                            .loc 3 152 0
 544 0330 38600001              li 3,1   #,
 545 0334 48000001              bl _Z5Sleepl     #
 153:N:/src/CTaskTemplateClass.cpp ****                 u8++;
 546                            .loc 3 153 0
 547 0338 893F000C              lbz 9,12(31)     # u8, u8
 548 033c 38090001              addi 0,9,1       # tmp158, u8,
 549 0340 981F000C              stb 0,12(31)     # u8, tmp158

I used exactly the same command line, I just switched path to binaries.
As the used 'as' is both the same it must be a change (regression?)
in gcc from 4.0 to 4.1. Or something new that as doesn't cope with yet.

Thanks

bye  Fabi