------- Comment #32 from hubicka at ucw dot cz 2010-04-06 11:05 ------- Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
> I think it is a really, really bad signal if a bug like this, where the > revision that introduced the issue was identified >9 months ago, remains > unfixed for GCC 4.5. This particular bug should not affect -Os scores at all as discussed earlier. Overall unit growth limits will never hit at -Os since we never enlarge unit size. I spent fair amount of time tracking down the individual CSiBE code size increases and fixed most of them. At the moment, I believe, the only remaining issue is bzip2 size growth. The inlining decisions here are sane at the local level as inliner sees them, just the resulting binary gets bigger. Inling is a heuristic even at -Os and we can't expect it to work in all cases. Here the old inliner got lucky by simply not accounting any stores/loads as real instructions allowing the functions to be inlined at letting later optimizers to produce smaller code. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436