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]
