This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 release criteria
- From: Stuart Hastings <stuart at apple dot com>
- To: Matt Austern <austern at apple dot com>
- Cc: Michael Hayes <m dot hayes at elec dot canterbury dot ac dot nz>, tm_gccmail at mail dot kloo dot net, Lars Segerlund <lars dot segerlund at comsys dot se>, gcc at gcc dot gnu dot org
- Date: Tue, 25 Feb 2003 14:03:49 -0800
- Subject: Re: GCC 3.3 release criteria
On Tuesday, Feb 25, 2003, at 13:00 US/Pacific, Matt Austern wrote:
On Tuesday, February 25, 2003, at 12:51 PM, Michael Hayes wrote:
tm_gccmail at mail dot kloo dot net writes:
My feelings exactly...for embedded programming and kernel work, you
need
an inline keyword that consistently inlines, regardless of the
setting of
the compiler switches or whatever.
I endorse this for small-scale embedded apps where you want the
convenience of a function call abstraction but not the expense of a
call instruction---some micros only have an 8 level call stack!
For general programming, I'm happy to defer to the wisdom of the
compiler.
This sounds like an argument in favor of a switch like Apple's
-fobey-inline. Programmers who are writing specialized code
and who need detailed control of low-level optimizations will
use that switch, others won't.
Again, I should remind people: Apple tried the experiment of
making -fobey-inline the default. The results were not good.
Specifically, indiscriminate use can provoke significant code bloat.
This sort of low-level control is sometimes useful, but it's
not useful as often as a lot of people think it is.
<platitude>
Like any tool, it can be misused.
</platitude>
If we do make -fobey-inline available (which I think we should),
then I encourage everyone to compile their code with and
without it, and look at the effect on code size, before adding
it to their makefiles.
Granted the evident interest, I will dust off "-fobey-inline",
regression-test it, and offer a patch.
stuart hastings
Apple Computer