This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Inlining (was: GCC 3.3 release criteria)
- From: Matt Austern <austern at apple dot com>
- To: Andi Kleen <ak at suse dot de>
- Cc: "Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu>, gcc at gcc dot gnu dot org, Stuart Hastings <stuart at apple dot com>
- Date: Mon, 24 Feb 2003 16:32:17 -0800
- Subject: Inlining (was: GCC 3.3 release criteria)
On Monday, February 24, 2003, at 12:28 PM, Andi Kleen wrote:
"Kaveh R. Ghazi" <ghazi at caip dot rutgers dot edu> writes:
<tr><td><a href="http://www.kernel.org">Linux kernel</a></td>
gcc 3.3 doesn't compile the linux kernels (2.4 and 2.5) very well
currently because the inlining algorithm is too broken. The Linux
kernel often assumes that functions marked "inline" get inlined and
when they aren't it results in linking errors. In a few rare cases
you also get silent miscompilation (this happened in the x86-64 port,
now fixed)
As it happens, Apple may be able to contribute a patch that does what
you're looking for. We've got a local patch that adds a new command
line switch, -fobey-inline. The switch does exactly what you think:
the
compiler will inline every function that's marked 'inline' whenever it's
possible. (There are still cases where it's not possible, of course,
e.g.
if you mark a recursive function inline.)
We definitely don't want -fobey-inline to be the default: usually it's
better for the compiler to treat the inline keyword as a hint, and to
use its own heuristics to decide when to accept the hint. But there are
cases, as you've found, when a flag like this is useful.
If Apple contributed the -fobey-inline patch, would people here be
interested in it?
--Matt