I maintain the ccache package in Fedora, and I'm forwarding a bug report from https://bugzilla.redhat.com/show_bug.cgi?id=488863 here, this seems reproducible (at least the second part, I suspect the CORRECT/INCORRECT in the first one are swapped, i.e. the first one is actually incorrect, the latter correct) with 3.0pre0: ---- Jan Kratochvil 2009-03-05 19:22:57 EST Description of problem: http://dwarf.freestandards.org/Dwarf3.pdf section 6.3.3 says the command-line macros should have line number of their definition zero. This is true for /usr/bin/gcc but in some cases `cache gcc' sets them non-zero. Version-Release number of selected component (if applicable): ccache-2.4-13.fc9.x86_64 gcc-4.3.2-7.x86_64 How reproducible: Always. CORRECT: $ : >empty.c; ccache gcc -c -o empty.o empty.c -g3; readelf -wm empty.o \ | grep __GNUC__ DW_MACINFO_define - lineno : 3 macro : __GNUC__ 4 INCORRECT: $ : >empty.c; /usr/bin/gcc -c -o empty.o empty.c -g3; readelf -wm empty.o \ | grep __GNUC__ DW_MACINFO_define - lineno : 0 macro : __GNUC__ 4 $ cat somefile.c int main (void) { return 0; } CORRECT: $ /usr/bin/gcc -c -o somefile.o somefile.c -Wall -g3; $ /usr/bin/gcc -o somefile somefile.o -Wall $ ~jkratoch/redhat/gdb-cvs-clean/gdb/gdb -q ./somefile (gdb) start Temporary breakpoint 1 at 0x400480: file somefile.c, line 4. Starting program: /tmp/somefile Temporary breakpoint 1, main () at somefile.c:4 4 return 0; (gdb) info macro __GNUC__ Defined at /tmp/somefile.c:0 #define __GNUC__ 4 INCORRECT: $ ccache gcc -c -o somefile.o somefile.c -Wall -g3 $ gcc -o somefile somefile.o -Wall $ ~jkratoch/redhat/gdb-cvs-clean/gdb/gdb -q ./somefile (gdb) start Temporary breakpoint 1 at 0x400480: file somefile.c, line 4. Starting program: /tmp/somefile Temporary breakpoint 1, main () at somefile.c:4 4 return 0; (gdb) info macro __GNUC__ Defined at /tmp/somefile.c:3 #define __GNUC__ 4 (gdb) l 1 int 2 main (void) 3 { 4 return 0; 5 } Single-step compilation (without the `somefile.o' intermediate) does not reproduce the problem.
Ville correctly pointed out the empty.c example has really swapped the CORRECT<->INCORRECT labels.
This is a consequence of how ccache normally works: It first runs the preprocessor on the source code, saves the output and (on a cache miss) passes the preprocessed source to the real compiler. And apparently, the correct line number information is not preserved when doing this manouver. There is a work-around: Set the CCACHE_CPP2 option. I have committed a fix in 574ab5a9af08b0639d38b623b2fb7d882272db50.