When a piece of code containing a multiline macro construct with embedded asm code is first preprocessed then compiled into an object or asm file, the results are different than directly compiling them into an object file or asm code.
The preprocessor step could take place when using -save-temps. It also happens when using ccache or distcc.
Linux kernel arm parts have this kind of code at least in
Created attachment 22691
example case
See the attached example case.
Also reported here: /bugs.launchpad .net/gcc- linaro/ +bug/687406
https:/
When a piece of code containing a multiline macro construct with embedded asm code is first preprocessed then compiled into an object or asm file, the results are different than directly compiling them into an object file or asm code.
The preprocessor step could take place when using -save-temps. It also happens when using ccache or distcc.
Linux kernel arm parts have this kind of code at least in
local_irq_restore() [include/ linux/irqflags. h] irq_restore( ) [arch/arm/ include/ asm/irqflags. h]
-> raw_local_
----
Result of example case without -save-temps:
.file "test.c"
.cfi_startproc
.text
.globl optimized
.type optimized, @function
optimized:
.LFB0:
#APP
# 15 "/tmp/test.c" 1
nop
# 0 "" 2
.cfi_endproc stack," ",@progbits
#NO_APP
ret
.LFE0:
.size optimized, .-optimized
.ident "GCC: (GNU) 4.5.1"
.section .note.GNU-
----
Result of example case with -save-temps:
.file "test.c"
.cfi_startproc
.text
.globl optimized
.type optimized, @function
optimized:
.LFB0:
testb $1, flags(%rip)
je .L2
#APP
# 15 "/tmp/test.c" 1
nop
# 0 "" 2
#NO_APP
ret
.L2:
#APP
# 15 "/tmp/test.c" 1
nop
# 0 "" 2
.cfi_endproc stack," ",@progbits
#NO_APP
ret
.LFE0:
.size optimized, .-optimized
.ident "GCC: (GNU) 4.5.1"
.section .note.GNU-