Bug#106716: gcc-3.0.1 refuses to compile Linux kernel

["Petr Vandrovec" <VANDROVE@vc.cvut.cz>]

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
                                            vandrove@vc.cvut.cz