GCC 3.3 release criteria

[Franz Sirl]

On Monday 24 February 2003 21:37, Daniel Jacobowitz wrote:
> On Mon, Feb 24, 2003 at 09:28:51PM +0100, Andi Kleen wrote:
> > "Kaveh R. Ghazi" <ghazi@caip.rutgers.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)
> >
> > Only good workaround currently is
> > -Dinline="__attribute__((always_inline))", just using
> > -finline-limit=hugenumber doesn't help.
> >
> > Better would be likely to fix the inlining heuristics to honor the inline
> > keyword better.
>
> I know this has been explained before, but maybe someone could do it
> again until it sticks...
>
> For functions marked with the "inline" keyword, as opposed to C++
> inline class methods, can anyone give me a reason why we don't treat
> the inline keyword as an always_inline attribute?

I wholeheartedly second that. If I write "inline" in C I expect that to happen 
as soon as the optimizer is turned on. If there is room for even more 
inlining after that, fine.
So, for C "inline" should be mapped to "always_inline".

Franz.