This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC 3.3 release criteria
- From: Daniel Jacobowitz <drow at mvista 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
- Date: Mon, 24 Feb 2003 15:37:19 -0500
- Subject: Re: GCC 3.3 release criteria
- References: <200302232354.SAA19348@caip.rutgers.edu.suse.lists.egcs-patches> <p73d6lh8lto.fsf@amdsimf.suse.de>
On Mon, Feb 24, 2003 at 09:28:51PM +0100, 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)
>
> 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?
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer