Comments in assember output

[Artur Krzysztof Szostak]

Is there a way to make GCC output the source code comments or corresponding
c++ source code that generated a set of assembler instructions in the .s
files?
The only thing that seems to come close is the -fverbose-asm switch, but this
does not give enough commentry for me to quickly and easily track down the
corresponding source line in the c++ source code.

--

Artur Szostak

Tel. [phone]
Mobile: [phone]
Emails: artur@...  artursz@...
AIM: artiblot
Skype: artiblot
Room: 4T6
Address:
R.W. James Building,
Rondebosch, 7701
Cape Town, South Africa

Physics Department
University of Cape Town

[Andrew Haley]

Artur Krzysztof Szostak writes:
 > Is there a way to make GCC output the source code comments or corresponding
 > c++ source code that generated a set of assembler instructions in the .s
 > files?

Yes.

-Wa,-adhls

Andrew.

[Artur Krzysztof Szostak]

Thanks, but this is not working.
The GNU assembler manpages do not indicate that 'as' knows this option.
Which version are you using?

My gcc versions and assembler versions are:

gcc version 3.4.4 20050721 (Red Hat 3.4.4-2)

GNU assembler version 2.15.92.0.2 (i386-redhat-linux) using BFD version
2.15.92.0.2 20040927


On Friday 24 November 2006 17:44, Andrew Haley wrote:

> Artur Krzysztof Szostak writes:
>  > Is there a way to make GCC output the source code comments or
>  > corresponding c++ source code that generated a set of assembler
>  > instructions in the .s files?
>
> Yes.
>
> -Wa,-adhls
>
> Andrew.

--

Artur Szostak

Tel. [phone]
Mobile: [phone]
Emails: artur@...  artursz@...
AIM: artiblot
Skype: artiblot
Room: 4T6
Address:
R.W. James Building,
Rondebosch, 7701
Cape Town, South Africa

Physics Department
University of Cape Town

[Ian Lance Taylor-3]

Artur Krzysztof Szostak <artur@...> writes:

> Thanks, but this is not working.

It should work if you also pass the -g option.

> The GNU assembler manpages do not indicate that 'as' knows this option.
> Which version are you using?

The option has been there for a long time, and is documented.  Look
for the -a option.

Ian

[Artur Krzysztof Szostak]

> It should work if you also pass the -g option.
>
But I want the high level source with out the -g option. I want to see what
the assembly would look like with -O or event -O3. I basically want in the .s
file a comment containing the source code line and under it the generated
assembly code that corresponds to it. Something like what is possible with
VC++

> > The GNU assembler manpages do not indicate that 'as' knows this option.
> > Which version are you using?
>
> The option has been there for a long time, and is documented.  Look
> for the -a option.
>
OK, I see it now, was trying to search for the whole string -adhls as is.

Thanks.


--

Artur Szostak

Tel. [phone]
Mobile: [phone]
Emails: artur@...  artursz@...
AIM: artiblot
Skype: artiblot
Room: 4T6
Address:
R.W. James Building,
Rondebosch, 7701
Cape Town, South Africa

Physics Department
University of Cape Town

[Ian Lance Taylor-3]

Artur Krzysztof Szostak <artur@...> writes:

> > It should work if you also pass the -g option.
> >
> But I want the high level source with out the -g option. I want to see what
> the assembly would look like with -O or event -O3. I basically want in the .s
> file a comment containing the source code line and under it the generated
> assembly code that corresponds to it. Something like what is possible with
> VC++

I don't think there is any simple way to do this without using the -g
option.

Note that the -g option does not affect code generation in any way.
You can use -O3 with or without -g, and you will get the same code.

Ian

[Artur Krzysztof Szostak]

> I don't think there is any simple way to do this without using the -g
> option.
>
> Note that the -g option does not affect code generation in any way.
> You can use -O3 with or without -g, and you will get the same code.
>

Will the -g -O3 option truly give me code that executed at the same speed
as -O3? I was not aware of that. In that case -g is fine. But even with -g I
am not getting the result I want. I guess it is time for a specific example:
Lets say I have the fillowing code in test.cxx

float func(float a, float b)
{
        return a * b;
}

and try to generate the assembly with

g++ -g -O3 -Wa,-addhls test.cxx -S

I would get the following (This output is truncated, I left out all the debug
symbols at the end):

# ... bla bla bla...
.LFB2:
        .file 1 "test.cxx"
        .loc 1 3 0
.LVL0:
        pushl %ebp
.LCFI0:
        movl %esp, %ebp
.LCFI1:
        .loc 1 3 0
        flds 12(%ebp)
.LBB2:
        .loc 1 4 0
        fmuls 8(%ebp)
.LBE2:
        .loc 1 5 0
        leave
        ret
.LFE2:
        .size _Z4funcff, .-_Z4funcff
# ... etc ...


And I dont see any comments containing my c++ source lines. I would have
expected something like:

# ... bla bla bla...
.LFB2:
        .file 1 "test.cxx"
        .loc 1 3 0
#                     float func(float a, float b)
#                     {
.LVL0:
        pushl %ebp
#                              return a * b;
.LCFI0:
        movl %esp, %ebp
.LCFI1:
        .loc 1 3 0
        flds 12(%ebp)
.LBB2:
        .loc 1 4 0
        fmuls 8(%ebp)
.LBE2:
        .loc 1 5 0
        leave
        ret
#                       }
.LFE2:
        .size _Z4funcff, .-_Z4funcff
# ... etc ...


Any ideas how to get his kind of output?

--

Artur Szostak

Tel. [phone]
Mobile: [phone]
Emails: artur@...  artursz@...
AIM: artiblot
Skype: artiblot
Room: 4T6
Address:
R.W. James Building,
Rondebosch, 7701
Cape Town, South Africa

Physics Department
University of Cape Town

[malc-4]

On Thu, 30 Nov 2006, Artur Krzysztof Szostak wrote:

>> I don't think there is any simple way to do this without using the -g
>> option.
>>
>> Note that the -g option does not affect code generation in any way.
>> You can use -O3 with or without -g, and you will get the same code.
>>
>
> Will the -g -O3 option truly give me code that executed at the same speed
> as -O3? I was not aware of that. In that case -g is fine. But even with -g I
> am not getting the result I want. I guess it is time for a specific example:
> Lets say I have the fillowing code in test.cxx
>
> float func(float a, float b)
> {
> return a * b;
> }
>

[..snip..]

Something like
<transcript>
cas$ g++ -c -g -O3 -Wa,-ahl=cas.s cas.c
cas$ sed -n /func/,40p cas.s
   12                    .globl _Z4funcff
   13                            .type   _Z4funcff, @function
   14                    _Z4funcff:
   15                    .LFB3:
   16                            .file 1 "cas.c"
    1:cas.c         **** float func(float a, float b)
    2:cas.c         **** {
   17                            .loc 1 2 0
   18                    .LVL0:
   19 0000 55                    pushl   %ebp
   20                    .LCFI0:
   21 0001 89E5                  movl    %esp, %ebp
   22                    .LCFI1:
   23 0003 D9450C                flds    12(%ebp)
    3:cas.c         ****         return a * b;
   24                            .loc 1 3 0
   25                    .LBB2:
   26 0006 D84D08                fmuls   8(%ebp)
    4:cas.c         **** }
   27                            .loc 1 4 0
   28 0009 5D                    popl    %ebp
   29 000a C3                    ret
   32                            .size   _Z4funcff, .-_Z4funcff
  215 0012 66756E63              .string "func"
  233 0006 66756E63              .string "func"
</transcript>

perhaps

--
vale

[Tony Wetmore]

Artur,

I just tried playing around with this, and it appears the the "-S" flag
is interfering.  Perhaps by stopping the compilation process in that
way, it prevents the generation of the "listing file".

I tried compiling your example function as follows:

   gcc -c -g -O3 -Wa,-adhls=func.list func.c

And got the following output (in func.list):

    1                            .file   "func.c"
    4                            .text
    5                    Ltext0:
   28                            .p2align 4,,15
   32                    .globl _func
   34                    _func:
    1:func.c        **** float func( float a, float b )
    2:func.c        **** {
   36                    LM1:
   37 0000 55                    pushl   %ebp
   38 0001 89E5                  movl    %esp, %ebp
   40                    LM2:
   41 0003 D9450C                flds    12(%ebp)
    3:func.c        ****   return a * b;
   43                    LM3:
   44 0006 D84D08                fmuls   8(%ebp)
    4:func.c        **** }
   46                    LM4:
   47 0009 5D                    popl    %ebp
   48 000a C3                    ret
   50                    Lscope0:
   52                            .text
   54 000b 90909090      Letext:
   54      90

This appears to be the sort of output you are looking for, right?

--
Tony Wetmore
Solipsys Corporation (http://www.solipsys.com)
mailto:tony.wetmore@...


Artur Krzysztof Szostak wrote:

>> I don't think there is any simple way to do this without using the -g
>> option.
>>
>> Note that the -g option does not affect code generation in any way.
>> You can use -O3 with or without -g, and you will get the same code.
>>
>
> Will the -g -O3 option truly give me code that executed at the same speed
> as -O3? I was not aware of that. In that case -g is fine. But even with -g I
> am not getting the result I want. I guess it is time for a specific example:
> Lets say I have the fillowing code in test.cxx
>
> float func(float a, float b)
> {
> return a * b;
> }
>
> and try to generate the assembly with
>
> g++ -g -O3 -Wa,-addhls test.cxx -S
>
> I would get the following (This output is truncated, I left out all the debug
> symbols at the end):
>
> # ... bla bla bla...
> .LFB2:
> .file 1 "test.cxx"
> .loc 1 3 0
> .LVL0:
> pushl %ebp
> .LCFI0:
> movl %esp, %ebp
> .LCFI1:
> .loc 1 3 0
> flds 12(%ebp)
> .LBB2:
> .loc 1 4 0
> fmuls 8(%ebp)
> .LBE2:
> .loc 1 5 0
> leave
> ret
> .LFE2:
> .size _Z4funcff, .-_Z4funcff
> # ... etc ...
>
>
> And I dont see any comments containing my c++ source lines. I would have
> expected something like:
>
> # ... bla bla bla...
> .LFB2:
> .file 1 "test.cxx"
> .loc 1 3 0
> #                     float func(float a, float b)
> #                     {
> .LVL0:
> pushl %ebp
> #                              return a * b;
> .LCFI0:
> movl %esp, %ebp
> .LCFI1:
> .loc 1 3 0
> flds 12(%ebp)
> .LBB2:
> .loc 1 4 0
> fmuls 8(%ebp)
> .LBE2:
> .loc 1 5 0
> leave
> ret
> #                       }
> .LFE2:
> .size _Z4funcff, .-_Z4funcff
> # ... etc ...
>
>
> Any ideas how to get his kind of output?
>

[Artur Krzysztof Szostak]

>
> Something like
> <transcript>
> cas$ g++ -c -g -O3 -Wa,-ahl=cas.s cas.c
> cas$ sed -n /func/,40p cas.s

This works thank you.
But I wonder why should not work with
g++ -S -g -O3 -Wa,-ahl=cas.s cas.c
like I was trying.

--

Artur Szostak

Tel. [phone]
Mobile: [phone]
Emails: artur@...  artursz@...
AIM: artiblot
Skype: artiblot
Room: 4T6
Address:
R.W. James Building,
Rondebosch, 7701
Cape Town, South Africa

Physics Department
University of Cape Town

[Tony Wetmore]

Artur,

After thinking about this some more, I believe the problem is that the
"-S" flag tells the driver (gcc) to stop after the compiler generates
the assembly code.  In other words, it never actually runs the assembler.

And since the assembler is the process that generates the listing file,
no listing output is ever generated.

I do not know why the mixed source/assembly listing is generated by the
assembler, rather than the compiler, but I am sure there is a good
technical reason for that, possibly having to do with optimizations made
by the assembler. :)

--
Tony Wetmore
Solipsys Corporation (http://www.solipsys.com)
mailto:tony.wetmore@...


Artur Krzysztof Szostak wrote:

>> Something like
>> <transcript>
>> cas$ g++ -c -g -O3 -Wa,-ahl=cas.s cas.c
>> cas$ sed -n /func/,40p cas.s
>
> This works thank you.
> But I wonder why should not work with
> g++ -S -g -O3 -Wa,-ahl=cas.s cas.c
> like I was trying.
>

[Ian Lance Taylor-3]

Tony Wetmore <tony.wetmore@...> writes:

> I do not know why the mixed source/assembly listing is generated by
> the assembler, rather than the compiler, but I am sure there is a good
> technical reason for that, possibly having to do with optimizations
> made by the assembler. :)

No, it's just a hack.

Ian

[Fabian Cenedese]

At 12:02 30.11.2006 -0500, Tony Wetmore wrote:

>Artur,
>
>I just tried playing around with this, and it appears the the "-S" flag is interfering.  Perhaps by stopping the compilation process in that way, it prevents the generation of the "listing file".
>
>I tried compiling your example function as follows:
>
>  gcc -c -g -O3 -Wa,-adhls=func.list func.c
>
>And got the following output (in func.list):
>
>   1                            .file   "func.c"
>   4                            .text
>   5                    Ltext0:
>  28                            .p2align 4,,15
>  32                    .globl _func
>  34                    _func:
>   1:func.c        **** float func( float a, float b )
>   2:func.c        **** {
>  36                    LM1:
>  37 0000 55                    pushl   %ebp
>  38 0001 89E5                  movl    %esp, %ebp
>  40                    LM2:
>  41 0003 D9450C                flds    12(%ebp)
>   3:func.c        ****   return a * b;
>  43                    LM3:
>  44 0006 D84D08                fmuls   8(%ebp)
>   4:func.c        **** }
>  46                    LM4:
>  47 0009 5D                    popl    %ebp
>  48 000a C3                    ret
>  50                    Lscope0:
>  52                            .text
>  54 000b 90909090      Letext:
>  54      90
>
>This appears to be the sort of output you are looking for, right?

That sounds usefull, I could use that as well. 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. There are several
functions in the cpp file, so at least those should be separatable
in the assembler code. I compiled without optimization so the
functions should not be intermingled. I tried the various -a flags
but it didn't work so far.

gcc 4.1.0, gas 2.16.1

Thanks

bye  Fabi

[Andrew Haley]

Fabian Cenedese writes:
 > At 12:02 30.11.2006 -0500, Tony Wetmore wrote:
 > >Artur,
 > >
 > >I just tried playing around with this, and it appears the the "-S" flag is interfering.  Perhaps by stopping the compilation process in that way, it prevents the generation of the "listing file".
 > >
 > >I tried compiling your example function as follows:
 > >
 > >  gcc -c -g -O3 -Wa,-adhls=func.list func.c
 > >
 > >And got the following output (in func.list):
 > >
 > >   1                            .file   "func.c"
 > >   4                            .text
 > >   5                    Ltext0:
 > >  28                            .p2align 4,,15
 > >  32                    .globl _func
 > >  34                    _func:
 > >   1:func.c        **** float func( float a, float b )
 > >   2:func.c        **** {
 > >  36                    LM1:
 > >  37 0000 55                    pushl   %ebp
 > >  38 0001 89E5                  movl    %esp, %ebp
 > >  40                    LM2:
 > >  41 0003 D9450C                flds    12(%ebp)
 > >   3:func.c        ****   return a * b;
 > >  43                    LM3:
 > >  44 0006 D84D08                fmuls   8(%ebp)
 > >   4:func.c        **** }
 > >  46                    LM4:
 > >  47 0009 5D                    popl    %ebp
 > >  48 000a C3                    ret
 > >  50                    Lscope0:
 > >  52                            .text
 > >  54 000b 90909090      Letext:
 > >  54      90
 > >
 > >This appears to be the sort of output you are looking for, right?
 >
 > That sounds usefull, I could use that as well. 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. There are several
 > functions in the cpp file, so at least those should be separatable
 > in the assembler code. I compiled without optimization so the
 > functions should not be intermingled. I tried the various -a flags
 > but it didn't work so far.

That's the way that gcc works.  The optimizers rearrange the functions
and output them in dependency order.  "-fno-unit-at-a-time" might
help.

Andrew.

[Fabian Cenedese]

> > >   1:func.c        **** float func( float a, float b )
> > >   2:func.c        **** {
> > >  36                    LM1:
> > >  37 0000 55                    pushl   %ebp
> > >  38 0001 89E5                  movl    %esp, %ebp
> > >  40                    LM2:
> > >  41 0003 D9450C                flds    12(%ebp)
> > >
> > >This appears to be the sort of output you are looking for, right?
> >
> > That sounds usefull, I could use that as well. 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. There are several
> > functions in the cpp file, so at least those should be separatable
> > in the assembler code. I compiled without optimization so the
> > functions should not be intermingled. I tried the various -a flags
> > but it didn't work so far.
>
>That's the way that gcc works.  The optimizers rearrange the functions
>and output them in dependency order.  "-fno-unit-at-a-time" might
>help.

Even if I don't use optimization? But it didn't help either, still big
blocks of code. With -fverbose-asm I see the switch on and off,
but the rest of the output is exactly the same.

bye   Fabi

[Andrew Haley]

Fabian Cenedese writes:
 >
 > > > >   1:func.c        **** float func( float a, float b )
 > > > >   2:func.c        **** {
 > > > >  36                    LM1:
 > > > >  37 0000 55                    pushl   %ebp
 > > > >  38 0001 89E5                  movl    %esp, %ebp
 > > > >  40                    LM2:
 > > > >  41 0003 D9450C                flds    12(%ebp)
 > > > >
 > > > >This appears to be the sort of output you are looking for, right?
 > > >
 > > > That sounds usefull, I could use that as well. 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. There are several
 > > > functions in the cpp file, so at least those should be separatable
 > > > in the assembler code. I compiled without optimization so the
 > > > functions should not be intermingled. I tried the various -a flags
 > > > but it didn't work so far.
 > >
 > >That's the way that gcc works.  The optimizers rearrange the functions
 > >and output them in dependency order.  "-fno-unit-at-a-time" might
 > >help.
 >
 > Even if I don't use optimization?

Yes, we always output stuff in dep order.

 > But it didn't help either, still big blocks of code. With
 > -fverbose-asm I see the switch on and off, but the rest of the
 > output is exactly the same.

Don't know why this is.

Andrew.

[Fabian Cenedese]

> > >That's the way that gcc works.  The optimizers rearrange the functions
> > >and output them in dependency order.  "-fno-unit-at-a-time" might
> > >help.
> >
> > Even if I don't use optimization?
>
>Yes, we always output stuff in dep order.
>
> > But it didn't help either, still big blocks of code. With
> > -fverbose-asm I see the switch on and off, but the rest of the
> > output is exactly the same.
>
>Don't know why this is.

I think it's because of some static initializing code. Here's a snippet
(Last code line in cpp is on 161):

 159:N:/Indel-PPC/Tests/gccext3/applicat/src/CTaskTemplateClass.cpp ****
 160:N:/Indel-PPC/Tests/gccext3/applicat/src/CTaskTemplateClass.cpp ****        // end _TASK_CLASS_NAME_::Action
 161:N:/Indel-PPC/Tests/gccext3/applicat/src/CTaskTemplateClass.cpp **** }
 153                            .loc 3 161 0
 154 0000 9421FFD8              stwu 1,-40(1)    #,,
 155                    .LCFI8:
 156 0004 7C0802A6              mflr 0   #,
 157                    .LCFI9:
 158 0008 93E10024              stw 31,36(1)     #,
 159                    .LCFI10:
 160 000c 9001002C              stw 0,44(1)      #,
 161                    .LCFI11:
 162 0010 7C3F0B78              mr 31,1  #,
 163                    .LCFI12:
 164 0014 907F0018              stw 3,24(31)     # __initialize_p, __initialize_p
 165 0018 909F001C              stw 4,28(31)     # __priority, __priority
...(snip)...
 175                            .loc 3 65 0
 176 003c 3D200000              lis 9,.LC7@ha    # tmp125,
 177 0040 38090064              la 0,.LC7@l(9)   # tmp124,, tmp125
 178 0044 90010008              stw 0,8(1)       #, tmp124
 179 0048 3D200000              lis 9,.LC7@ha    # tmp127,

Various initializing code is put together and starts with the biggest line
number. So it's placed at the end of the source file lines and everything
after that must come later. Don't know...

bye  Fabi

[Fabian Cenedese]

> > >That's the way that gcc works.  The optimizers rearrange the functions
> > >and output them in dependency order.  "-fno-unit-at-a-time" might
> > >help.
> >
> > Even if I don't use optimization?
>
>Yes, we always output stuff in dep order.
>
> > But it didn't help either, still big blocks of code. With
> > -fverbose-asm I see the switch on and off, but the rest of the
> > output is exactly the same.
>
>Don't know why this is.

Actually it's only the given flag that changes, unit-at-a-time is always
enabled.

   4                     # GNU C++ version 4.1.0 (powerpc-eabi)
...(snip)...
   7                     # options passed:  -I -I -I -I -I -I -I -I -I -I -iprefix -DPPC603
...(snip)...
  10                     # -mcpu=603 -auxbase-strip -g -gdwarf-2 -Wall -fno-exceptions -fno-rtti
  11                     # -fverbose-asm -fno-unit-at-a-time -fno-tree-loop-optimize
  12                     # options enabled:  -falign-loops -fargument-alias -fbranch-count-reg
...(snip)...
  19                     # -ftree-vect-loop-version -funit-at-a-time -fverbose-asm

Is unit-at-a-time now always enabled, despite -fno-unit-at-a-time?
I also saw other optimization flags that are supposed to be only
enabled with O2 or O3 (like -falign-loops, at least according to docs)

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html#Optimize-Options

But the options passed show that there's no (hidden) optimization enabled.

bye   Fabi

[John Yates-2]

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 am writing from rather foggy memories but I believe that the fix was
to mark instructions with both a putative line number and a boolean
flag indicating whether or not the instruction corresponded to a
significant source side-effect.  The listing format included a source
line number as an end-of-line comment.  Thus a motioned expression
could still be traced back to a source line.  Source lines were merged
into the assembly file using the classic scheme alluded to above with
the following refinement.  When an assembly instruction included a source
line correlation higher than the most recently merged source line that
line number correlation was ignored unless either a) that instruction was
flagged as a significant side-effect or b) there was an uninterrupted run
of instructions with that same line number correlation ultimately leading
to an instruction that was flagged as a significant side-effect.

As I recall the motivation for making these changes was not more readable
assembly listing but a need for saner information in the debugger's pc
correlation table.

/john

[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