As Eric Weddington wrote: > > > And it seems to have some issues: > > > <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31528> Comments #4 > > > and #6.
> > The only real issue here is a wrong expectation: That a certain > > combination of flags magically does the best thing for every > > target. No, the issue is that the -Os option is *documented* to *only* include those optimizations that are known to not increase the code size. It is all fine with me to have automatic inlining of functions if and only if that does not increase the code size -- because, after all, that is the main idea behind -Os: to get the smallest code size possible. Since that bug report shows that the inlining as implemented now increases the code size (for that test case) for every target where it has been tested on so far, this is clearly in violation of the rules for -Os, and thus a regression compared to older versions of GCC (which generally didn't perform any automatic inlining with -Os). If you don't accept that to be a regression, what else are you willing to accept? > > Then, folks who like to complain > > come along and report silly bugs like this, > Wow. I hope you just had a bad day only. Otherwise, I might eventually lose my trust into the mental abilities of the GCC developers. Sorry. I spent a couple of hours to boil down the complaints of our users (some of them still think that GCC 4 is a major step backwards for them!, compared to GCC 3) to what really makes a meaningful bug report (simple, reproducible). I spent another couple of hours to demonstrate this regression basically affects *all* GCC targets (not just AVR which I realize is by now of quite minor importance), and what am I called for doing that? Sorry, but this is unbelievable. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
