Re: Inlining (was: GCC 3.3 release criteria)

[Andi Kleen <ak at suse dot de>]

On Mon, Feb 24, 2003 at 04:32:17PM -0800, Matt Austern 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.)

Yes, that is why I don't like the -Dinline="__attribute__((always_inline)) inline"
way too much - there are a few valid reasons why inline functions marked
inline didn't get inlined and this define changes behaviour for them
by essentially forcing -Winline -Werror

> If Apple contributed the -fobey-inline patch, would people here be
> interested in it?

I would still prefer if inline was much stronger for C programs by default
(I realize that the situation is different for C++ where inline is used
much more frequently and in a different way), but failing that
-fobey-inline would be useful too. The problems seem to root in trying
to handle C and C++ with the same heuristics.

Preferably for 3.3 too then.

-Andi