Andrew Morton <akpm@digeo.com> writes:
> This patch:
[...]
I submitted a similar patch (using -include) it to Linus some time ago.
It's even required to work around gcc 3.3 inlining bugs.
Unfortunately he didn't like it and prefered __force_inline
to be added to the places that really rely on inline.
I experimented with -finline-limit=<huge number> to get it to obey inline,
but that doesn't fully work. The only way to get it to work in 3.2 and 3.3
is to specify various long and weird --param arguments. In 3.0 the only
way is to change the values in the compiler source and recompile.
So doing it with always_inline is much less ugly and also less compiler
version dependent.
I always add them currently by hand to linux/brlock.h to get 2.5
to compile with gcc 3.3 on x86-64.
I think it is the right thing to do. In kernel land when we say inline
we mean inline. Don't expect the compiler to second guess that,
especially since it doesn't seem to be very good at that.
There was also talk on the gcc mailing list to add an
-fobey-inline switch, but nothing got out of it. And it would be 3.3+
only anwyays.
I didn't see a 64K shrink however on x86-64, but I guess that's
because it has a much cleaner uaccess.h ;) For i386 it is a nice bonus.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Mar 07 2003 - 22:00:31 EST