Re: Bug#106716: gcc-3.0.1 refuses to compile Linux kernel
On Thu, 26 Jul 2001, Petr Vandrovec wrote:
> > Why not have the kernel Makefile pass "-flimit-inline=10000" explicitly?
>
> Because of I see no reason for breaking documented behavior - also my
He's got a point here. The documentation says that the inlining limit
default is 10000. I'll have to check upstream CVS to see if this has been
fixed in documentation or code (or neither).
> 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).
Ok, to clarify what I think you're trying to say:
gcc 2.95.x used -finline-limit-N
gcc 3.0.x uses -finline-limit=N
(no, that's not a typo on my part...the hyphen was replaced by an equal
sign according to the docs)
Since neither 2.95.x or 3.0.x understand the other's options, it's
not inlining the code that needs to be? I understand what the various gcc
passes do WRT inlining, so no need to explain that portion...I'm just
trying to understand why changing the kernel Makefile is such a big deal,
especially since the kernel folks haven't began recommending that the
kernel be compiled with gcc 3.0.x yet anyway. There are MANY more
pitfalls involved in compiling kernels with gcc 3.0.x on some
platforms. I've had to patch Alpha's kernel sources just to compile the
kernel at all with gcc 3.0.
For the record, according to 2.4.6's Documentation/Changes file:
The recommended compiler for the kernel is egcs 1.1.2 (gcc 2.91.66), and
it should be used when you need absolute stability. You may use gcc 2.95.x
instead if you wish, although it may cause problems. Later versions of gcc
have not received much testing for Linux kernel compilation, and there are
almost certainly bugs (mainly, but not exclusively, in the kernel) that
will need to be fixed in order to use these compilers. In any case, using
pgcc instead of egcs or plain gcc is just asking for trouble.
> 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
I haven't really testing inlining behaviour much with 3.0.x yet, so I
don't know what it's doing, but at least IMO, adding such an option
doesn't make much sense. 3.0 is different on the backend than its
predecessors, so the default options may change depending on what the
backend now does (and doesn't do). If that changes expected behaviour on
a target or two, then documentation is usually how the issue is
handled. Basically, there are usually good reasons why such behaviour
changes occur. It's possible that you've encountered a bona fide bug here
(I believe that you have), but we'll have to see if the bug is
documentation-related or code-related (meaning their code, not
yours).
> 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...
Hmm...I'm definitely going to have to play with this. Can you come up
with a small testcase so that I can test other architectures as well?
C
Reply to: