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
