[Bug gcov-profile/100289] [11/12 Regression] libgcc/libgcov.h: bootstrap failure due to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100289 --- Comment #18 from Joerg Wunsch --- (In reply to rudi from comment #17) > The issue is still there during the bootstrap build, but maybe > --disable-gcov might help you in your cross compile toolchain too. Yes, --disable-gcov does help as well. I just wasn't sure whether having gcov support might make sense on a cross-compiler or not, and as the FreeBSD port did have it enabled before, I was merely tempted to do it that way. But yes, it's probably questionable whether anyone would really run gcov on an AVR. ;-)
[Bug gcov-profile/100289] [11/12 Regression] libgcc/libgcov.h: bootstrap failure due to missing #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100289 Joerg Wunsch changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #16 from Joerg Wunsch --- Can confirm this bug when building an AVR cross-compiler (11.2) on FreeBSD. To get it working, I'm now patching it to #undef HAVE_SYS_MMAN_H in libgcov.h before starting.
[Bug c/62084] New: [avr] ICE: in convert_debug_memory_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62084 Bug ID: 62084 Summary: [avr] ICE: in convert_debug_memory_address Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: j at uriah dot heep.sax.de Created attachment 33286 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33286action=edit Preprocessed source triggering the issue When compiling the SVN version of avr-libc, I get the following ICE: % env LANG=C avr-gcc -gdwarf-2 -Wall -W -Wstrict-prototypes -mmcu=avr2 -mcall-prologues -Os -S strftime.i ../../../libc/time/strftime.c: In function 'pgm_copystring': ../../../libc/time/strftime.c:56:1: internal compiler error: in convert_debug_memory_address, at cfgexpand.c:2528 pgm_copystring(const char __memx * p, unsigned char i, char *b, unsigned char l) ^ no stack trace because unwind library not available Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. This can also be observed with GCC 4.8.3. Omitting the -gdwarf-2 option makes the issue go away.
[Bug c/59301] Please enable -Wstrict-overflow as part of -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Joerg Wunsch j at uriah dot heep.sax.de --- Agreed.
[Bug c/59301] Please enable -Wstrict-overflow as part of -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Joerg Wunsch j at uriah dot heep.sax.de --- Agreed with Vincent. (Mandatory comment needed. ;-)
[Bug c/59301] New: Please enable -Wstrict-overflow as part of -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59301
Bug ID: 59301
Summary: Please enable -Wstrict-overflow as part of -Wextra
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: j at uriah dot heep.sax.de
The -fstrict-overflow behaviour can lead to surprising results. Consider
the following code that came up in a forum, complaining about why GCC
optimizes the first loop into an endless one:
int main (void)
{
int i = 0;
while (--i)
asm(nop);
for (;;);
}
The (obvious, in that short piece of code) expectation of the programmer
was that the NOP is executed a finite number of times (basically, just
waiting a bit that way), and the code flow then proceeds to the final
infinite loop.
Instead, the resulting code is an infinite loop around the NOP statement.
(The original question came out for the AVR target, but the behaviour is
completely independent of the actual target.)
Specifying the commonly used -Wall -Wextra options doesn't tell the innocent
programmer the compiler basically already detected some undefined behaviour,
and might have reordered the code due to that undefined behaviour. Only
by specifying -Wstrict-overflow, one gets:
foo.c: In function 'main':
foo.c:4:11: warning: assuming signed overflow does not occur when simplifying
conditional to constant [-Wstrict-overflow]
I think it would be much better to include -Wstrict-overflow into -Wextra,
so people get aware of the potential problems.
[Bug driver/28718] Call to -lgcc added prior to user libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718 --- Comment #13 from Joerg Wunsch j at uriah dot heep.sax.de 2012-09-05 15:08:27 UTC --- All this is fighting the symptoms though. My point (as outlined in comment #8: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718#c8 ) is: When operating as a C compiler, *all* user-supplied libraries are passed to the linker *first*, followed by system libraries. When operating as a C++ compiler, libstdc++ and libm.a are passed *before* any user-supplied library. This leaves the users in a situation where they are no longer able to supply own overrides for some functions in system libraries. Again, all this is in contrast to how the C compiler works. In the AVR case, the situation is only worse since there's no libstdc++ (yet), and somehow, libgcc is substituted in place of libstdc++ (which I think is a completely flawed idea from the beginning). So despite all the artefacts which leaded to this bug report, I think at least the last point mentioned is worth fixing: if there's no libstdc++, there's no point in trying to pretend libgcc could be supplied as a replacement for libstdc++. (The AVR-related artefacts are now mostly fixed after Johann's recent work, the original bug(s) remain(s).)
[Bug target/52488] avr-*: internal compiler error: in extract_insn, at recog.c:2123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52488 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #10 from Joerg Wunsch j at uriah dot heep.sax.de 2012-03-13 07:02:51 UTC --- (In reply to comment #9) Or do you want GCC to print out how much RAM each device has? No, I would expect GCC to print its rationale for this rejection. e.g. something like allocating 2050 byte of stack exceeds maximum stack size (1024 bytes) ... There is no fixed stack size in GCC. It's just the SRAM size sets an upper limit for the largest possible stack size. Thus Eric's question about printing out the RAM size.
[Bug driver/28718] Call to -lgcc added prior to user libraries
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28718
--- Comment #11 from Joerg Wunsch j at uriah dot heep.sax.de 2011-11-28
19:45:51 UTC ---
(In reply to comment #10)
Jörg, could you prepare a list of functions that shall be excluded from
libgcc?
You can also answer to my mail PR28718 Infos? from 2011-11-10.
Well, perhaps. However, the AVR-part is not the main subject of my
complaint here. The subject of my complaint was/is that a call to
*any* library is added *prior* to the list of user-supplied libaries
(from -l options). The point of -l options is to give the users an
override option, which is completely defeated by the current way
libstdc++ is handled.
The fact that the AVR (currently) lacks a libstdc++, and thus libgcc
is linked instead, caused this bug to be escalated due to the side
effects, but this is not the main point here.
This becomes even more puzzling now: apparently, this reordering of
the libraries *only* applies to -lm. When specifying any other
library, the processing works as one would expect it to be.
The code for this is in gcc/cp/g++spec.c, around line 270:
/* Make sure -lstdc++ is before the math library, since libstdc++
itself uses those math routines. */
if (!saw_math (args[i] MATHLIB) library 0)
{
--j;
saw_math = decoded_options[i];
}
OK, now the reason is clear. However, this doesn't handle the case
very well where no libstdc++ is available at all: inserting libgcc in
place of libstdc++ is just a simple workaround, and apparently a too
simple one in our case. A correct implementation would not try to add
anything at all when libstdc++ is unavailable (and thus have no need
to reorder).
I don't know how many targets are affected at all by the lack of
libstdc++. If AVR is indeed the only target where this applies to,
then the way you outlined (a configurable list of functions to omit
from libgcc) might be the best compromise.
(Sorry it took me so long to reply, Johan, but I knew it would take me
some time to research all this again, and then create the reply.)
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #15 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-28 06:27:17 UTC --- (In reply to comment #14) . Regardless of whether someone votes to remove an option, a segfault should always be analyzed. Except that this is a segfault on a compiler switch that is unmaintained, Did you analyze it to make sure there is no chance for this to happen also without -mint8? OK, I did, and it's indeed the case. unmaintained — by the original maintainers. The people contributing (patches!) to this bug report demonstrate there actually *is* some effort to still maintain it — by the users. Why ignore this effort, and do it away as we don't want to maintain that anymore? The only drawback I could see with that patch is that it introduces a couple of #ifdefs outside of the AVR code path in the compiler, to give the AVR backend an override option for the type sizes. and there are little to no user complaints about it. That's simply because all the compiler versions that are out in the field (4.3.x, 4.4.x) still have a working (within their known limitations, of course) -mint8 option. Be assured, we will get complaints about it if you release another WinAVR with a non-working -mint8 option, or with the option dropped. Actually it does. The attiny10 series (attiny10/4/5/9/20/40) is still what I would call experimental, in that they are only in distros and not upstream, and you know as well as I do that there is a serious wrong-code bug with them anyway. That doesn't matter much. The wrong-code bug can (probably) be fixed, but the integer promotion issues won't be affected by that fix. If you don't like the reference to ATtiny10 (Co.), just keep the ATtiny13 (and probably also ATtiny2313, ATtiny25, ATtiny45) in your mind by now. As to the other small device users, those devices still use avr-libc They *can* use it. We've always told them however, that using -mint8 and avr-libc doesn't mix. Nevertheless, it appears to be useful enough to some users to decide pro -mint8 (and thus against using the library). (It isn't even entirely true that both don't mix: a lot of the library stuff just comes as inline functions and macros within the header files, and this part is likely working to a large degree even with -mint8.) We all know that the ideal solution is to fix the avr backend regarding optimizing (removing) unnecessary promotion. We can start by biting the bullet and removing -mint8. I'd do it the other way around: fix the optimization issues, until the users don't benefit from the -mint8 hack anymore. By that time, it can be removed without anyone complaining. You cannot impose any pressure to the *developers* (to fix the optimization issues) by removing the option now, but you'll cause some impact for users of that option — users who can't do anything about it other than voicing their complaints in public that more recent versions of GCC get worse and worse in their usability. I'd like to avoid this situation.
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 --- Comment #16 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-28 06:30:42 UTC --- Created attachment 24611 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24611 Fixed the filenames in the patch header. Fixed the filenames in the patch header (there have been two .orig too many). I can confirm the patch fixes the issue in question on GCC trunk.
[Bug target/46261] avr-gcc: Segfaults when compiled with the -mint8 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46261 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #12 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-27 08:02:15 UTC --- (In reply to comment #11) Let's remove it. Two things to consider: . Regardless of whether someone votes to remove an option, a segfault should always be analyzed. It's easy enough to otherwise just hide an error that will only reappear later on. . As long as the AVR backend has a substantial number of PRs open about missed optimization, related to [u]int8_t - int promotions, the -mint8 option should stay, as it appears to be useful in particular to people using very small controllers (ATtiny13, also think about the new ATtiny4/5/6/9 series). Non-applicability of this option to avr-libc is not a serious issue for those targets anyway, so this (counter-)argument doesn't count here.
[Bug target/49487] Internal compiler error in AVR code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49487 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #2 from Joerg Wunsch j at uriah dot heep.sax.de 2011-06-21 15:57:50 UTC --- Confirmed for current SVN trunk (r175263). I cannot reproduce it on GCC 4.3.4.
[Bug middle-end/48395] New: [AVR] ICE: segmentation fault when compiling libgcc2.c, SVN trunk r171783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48395 Summary: [AVR] ICE: segmentation fault when compiling libgcc2.c, SVN trunk r171783 Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@uriah.heep.sax.de Created attachment 23842 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23842 GDB transcript trunk r171783 cannot compile its own libgcc2.c for the AVR target: gmake[4]: Entering directory `/junk/gcc/trunk/build-avr/avr/avr25/libgcc' # If this is the top-level multilib, build all the other # multilibs. /junk/gcc/trunk/build-avr/./gcc/xgcc -B/junk/gcc/trunk/build-avr/./gcc/ -B/junk/testroot/avr/bin/ -B/junk/testroot/avr/lib/ -isystem /junk/testroot/avr/include -isystem /junk/testroot/avr/sys-include-g -O2 -mmcu=avr25 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc -I../../../../libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 -c ../../../../libgcc/../gcc/libgcc2.c \ ../../../../libgcc/../gcc/libgcc2.c: In function ‘__negdi2’: ../../../../libgcc/../gcc/libgcc2.c:68:17: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. gmake[4]: *** [_negdi2.o] Error 1 gmake[4]: Leaving directory `/junk/gcc/trunk/build-avr/avr/avr25/libgcc' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/junk/gcc/trunk/build-avr/avr/libgcc' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/junk/gcc/trunk/build-avr/avr/libgcc' gmake[1]: *** [all-target-libgcc] Error 2 gmake[1]: Leaving directory `/junk/gcc/trunk/build-avr' gmake: *** [all] Error 2 (Also attaching the GDB transcript separately for better readability. See below for my conclusion about the nature of the bug.) The debugger shows the following stack trace: (gdb) bt #0 scratch_operand (op=0x959, mode=HImode) at ../../gcc/recog.c:1078 #1 0x08375db4 in insn_operand_matches (icode=CODE_FOR_setmemhi, opno=4, operand=0x959) at ../../gcc/optabs.c:6999 #2 0x083760d9 in maybe_legitimize_operands (icode=CODE_FOR_setmemhi, opno=0, nops=5, ops=0xbfbfda2c) at ../../gcc/optabs.c:7074 #3 0x083762c3 in maybe_gen_insn (icode=CODE_FOR_setmemhi, nops=5, ops=0xbfbfda2c) at ../../gcc/optabs.c:7124 #4 0x083764cf in maybe_expand_insn (icode=CODE_FOR_setmemhi, nops=5, ops=0xbfbfda2c) at ../../gcc/optabs.c:7155 #5 0x08231f19 in set_storage_via_setmem (object=0x28b4f2dc, size=0x28a1b2f8, val=0x28a1b2b8, align=Variable align is not available. ) at ../../gcc/expr.c:2738 #6 0x08246b41 in clear_storage_hints (object=0x28b4f2dc, size=0x28a1b2f8, method=BLOCK_OP_NORMAL, expected_align=0, expected_size=-1) at ../../gcc/expr.c:2579 #7 0x08246c7f in clear_storage (object=0x28b4f2dc, size=0x28a1b2f8, method=BLOCK_OP_NORMAL) at ../../gcc/expr.c:2594 #8 0x08239a1d in store_constructor (exp=0x28b10848, target=0x28b4f2dc, cleared=0, size=8) at ../../gcc/expr.c:5196 #9 0x0823a729 in expand_constructor (exp=0x28b10848, target=0x28b4f2dc, modifier=EXPAND_NORMAL, avoid_temp_mem=0 '\0') at ../../gcc/expr.c:7100 #10 0x0823d56a in expand_expr_real_1 (exp=0x28b10848, target=0x28b4f2dc, tmode=BLKmode, modifier=EXPAND_NORMAL, alt_rtl=0xbfbfdd9c) at ../../gcc/expr.c:8659 #11 0x08246d53 in store_expr (exp=0x28b10848, target=0x28b4f2dc, call_param_p=0, nontemporal=0 '\0') at ../../gcc/expr.c:4653 #12 0x08236f47 in expand_assignment (to=0x28b2b120, from=0x28b10848, nontemporal=Variable nontemporal is not available. ) at ../../gcc/expr.c:4441 #13 0x081950a1 in expand_gimple_stmt (stmt=0x28b2f6c0) at ../../gcc/cfgexpand.c:1972 #14 0x08195a98 in expand_gimple_basic_block (bb=0x28a926c0) at ../../gcc/cfgexpand.c:3637 #15 0x08197028 in gimple_expand_cfg () at ../../gcc/cfgexpand.c:4120 #16 0x08391a57 in execute_one_pass (pass=0x881b120) at ../../gcc/passes.c:1555 #17 0x08391e9d in execute_pass_list (pass=0x881b120) at ../../gcc/passes.c:1610 #18 0x0847174a in tree_rest_of_compilation (fndecl=0x28afea00) at ../../gcc/tree-optimize.c:422 #19 0x0861c209 in cgraph_expand_function (node=0x28b09f24) at ../../gcc/cgraphunit.c:1575 #20 0x0861f842 in cgraph_optimize () at ../../gcc/cgraphunit.c:1634 #21 0x0861fd2a in cgraph_finalize_compilation_unit () at ../../gcc/cgraphunit.c:1095 #22 0x080a3998 in c_write_global_declarations () at ../../gcc/c-decl.c:9879 #23 0x0840af90 in do_compile () at ../../gcc/toplev.c:591 #24 0x0840b73d in toplev_main (argc=83,
[Bug middle-end/48395] [AVR] ICE: segmentation fault when compiling libgcc2.c, SVN trunk r171783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48395 --- Comment #1 from Joerg Wunsch j at uriah dot heep.sax.de 2011-03-31 19:13:13 UTC --- If I unpatch r171532 from gcc/expr.c (which introduced the current version of that piece of code), I don't get a segfault anymore but a different ICE: ../../../../libgcc/../gcc/libgcc2.c: In function ‘__negdi2’: ../../../../libgcc/../gcc/libgcc2.c:68:17: internal compiler error: in maybe_gen_insn, at optabs.c:7123 Please submit a full bug report,
[Bug target/45261] Doesn't indicate failure status when it doesn't support (attiny2313A)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45261 Joerg Wunsch j at uriah dot heep.sax.de changed: What|Removed |Added CC||j at uriah dot heep.sax.de --- Comment #7 from Joerg Wunsch j at uriah dot heep.sax.de 2010-11-22 10:23:53 UTC --- (In reply to comment #6) Here's a patch to implement change suggested above - added call to error(). I left in the existing fprintf() thinking that the list of supported MCUs is useful. I think just replacing the fprintf() by error() is fine. If anyone wants to know the list of supported MCUs, they can always use the --target-help option.
[Bug target/46426] New: [avr] avr/libgcc.S in SVN r166596 fails to compile
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46426 Summary: [avr] avr/libgcc.S in SVN r166596 fails to compile Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: j...@uriah.heep.sax.de Created attachment 22372 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22372 Suggested patch Trying to compile trunk/r166596 for the AVR target results in: /junk/gcc/trunk/build-avr/./gcc/xgcc -B/junk/gcc/trunk/build-avr/./gcc/ -B/junk/test/avr/bin/ -B/junk/test/avr/lib/ -isystem /junk/test/avr/include -isystem /junk/test/avr/sys-include-g -O2 -mmcu=avr25 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -Os -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../libgcc -I../../../../libgcc/. -I../../../../libgcc/../gcc -I../../../../libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _exit.o -MT _exit.o -MD -MP -MF _exit.dep -DL_exit -xassembler-with-cpp \ -c ../../../../libgcc/../gcc/config/avr/libgcc.S ../../../../libgcc/../gcc/config/avr/libgcc.S: Assembler messages: ../../../../libgcc/../gcc/config/avr/libgcc.S:655: Error: operation combines symbols in different segments gmake[4]: *** [_exit.o] Error 1 gmake[4]: Leaving directory `/junk/gcc/trunk/build-avr/avr/avr25/libgcc' gmake[3]: *** [multi-do] Error 1 gmake[3]: Leaving directory `/junk/gcc/trunk/build-avr/avr/libgcc' gmake[2]: *** [all-multi] Error 2 gmake[2]: Leaving directory `/junk/gcc/trunk/build-avr/avr/libgcc' gmake[1]: *** [all-target-libgcc] Error 2 gmake[1]: Leaving directory `/junk/gcc/trunk/build-avr' gmake: *** [all] Error 2 The preprocessed source for this is: # 642 ../../../../libgcc/../gcc/config/avr/libgcc.S .section .fini9,ax,@progbits .global _exit .func _exit _exit: .weak exit exit: .section .fini0,ax,@progbits cli __stop_program: rjmp __stop_program .endfunc It complains about .endfunc. My guess is another .func/.endfunc is needed between _exit and __stop_program. Applying the following patch seems to fix this issue: Index: gcc/config/avr/libgcc.S === --- gcc/config/avr/libgcc.S(revision 166596) +++ gcc/config/avr/libgcc.S(working copy) @@ -646,9 +646,11 @@ .weakexit exit: +.endfunc /* Code from .fini8 ... .fini1 sections inserted by ld script. */ .section .fini0,ax,@progbits +.func__stop_program cli __stop_program: rjmp__stop_program
[Bug middle-end/31528] Inlining with -Os increases code size
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).
