http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528
--- Comment #11 from Joerg Wunsch <j at uriah dot heep.sax.de> 2010-11-11
10:59:42 UTC ---
(In reply to comment #10)
> Can you, please, test if current mainline behave more resonably?
Well, I had to fix bug #46426 first ...
Yes, that looks good now. Compiling the original testcase with just
-Os (no -fno-inline involved) results in:
.type putch, @function
putch:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
.L2:
sbis 43-0x20,5
rjmp .L2
out 44-0x20,r24
/* epilogue start */
ret
.size putch, .-putch
.global main
.type main, @function
main:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(0)
rcall putch
ldi r24,lo8(1)
rcall putch
ldi r24,lo8(2)
rcall putch
ldi r24,lo8(3)
rcall putch
ldi r24,lo8(4)
rcall putch
ldi r24,lo8(5)
rcall putch
ldi r24,lo8(6)
rcall putch
ldi r24,lo8(7)
rcall putch
ldi r24,lo8(8)
rcall putch
ldi r24,lo8(9)
rcall putch
ldi r24,lo8(0)
ldi r25,hi8(0)
/* epilogue start */
ret
.size main, .-main
That's the same what has originally been compiled when applying
-fno-inline.
It does not solve the issue from bug #30908 though. The version
compiled with -DNOINLINE there is still 4 bytes smaller than the
default version (which has already been the case in GCC 4.3.4).
However, both versions are now already considerably smaller than they
used to be in 4.3.4 (40/44 bytes vs. 52/56 bytes in 4.3.4).
