On 26 Jul 01 at 16:11, Ben Collins wrote: > On Thu, Jul 26, 2001 at 08:27:14PM +0200, Petr Vandrovec wrote: > > Package: gcc-3.0 > > Version: 3.0.1-0pre010723
> > to change code to not inline, and I agree with him - 100 is completely > > stupid, backward incompatible limit. Even rebuilding kernel with > > -flimit-inline=200 fixed problem for my particular kernel, but going > > back to 10000 is definitely preferred variant. > > I hope for quick reverting back. > > Why not have the kernel Makefile pass "-flimit-inline=10000" explicitly? Because of I see no reason for breaking documented behavior - also my ncpfs code is affected by this (fortunately it still links as I gave up teaching gcc to inline code long ago). And as there is no documentation since when this option is supported, it is just guessing (or someone has to add -flimit-inline check to autoconf or kernel makefile). If you think that it is reasonable to use limit-inline=100 as default, would it be possible for next gcc version to add option '-fuse-default=<gcc-version[:date]>' which would select defaults as they were for specified gcc-version (such as no strict aliasing, large inline limit, no 16byte stack alignment...)? I know that it is dumb idea, but if gcc refuses to inline copy_siginfo, which is just extern inline void copy_siginfo(siginfo_t* to, siginfo_t* from) { if (from->si_code < 0) memcpy(to, from, sizeof(siginfo_t)); else memcpy(to, from, 3*sizeof(int) + sizeof(from->_sifields._sigchld)); } then I think that there is something wrong... Best regards, Petr Vandrovec [EMAIL PROTECTED]