This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Inlining (was: GCC 3.3 release criteria)
On Mon, 24 Feb 2003 16:32:17 -0800 Matt Austern <austern at apple dot com> wrote:
> 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.
>
this confuses me a bit. i always thought, that the "inline" keyword would
in any case force inlining, except for the -fno-inline flag activated.
IMHO, the compiler should always obey user inlining, because the compiler
should trust the programmer when he uses an optional feature (such as inline).
for me, the question evolves: what does happen in -Os optimization? i suppose,
there isn't done any inline at all, not even explicitely "inline" marked
functions, no?
brg,
Tolga Dalman.