Re: gcc 3.1 fails to build Linux 2.4.7 kernel on i686-linux

["Bill Beebe" <wbeebe at cfl dot rr dot com>]

I compiled 2.4.17 with the pre-emption patch applied
(http://kpreempt.sourceforge.net). The distribution was RedHat 7.2 running
under RedHat's latest official kernel (2.4.9-21) and library updates at the
time of the compilation test. The version of gcc 3.1 I built was 20020311.
When I built this version of 3.1 I built everything. After successfully
building my version of 2.4.17 with gcc 3.1, I attempted to boot it, but the
kernel panicked (which at this time isn't surprising). I've also built gcc
under cygwin (1.3.10) on Windows 2000 SP2. So far, with the limited work I've
cross compiled with 3.1 pre-releases, I have not been surprised or greatly
disappointed.

You'll note that the kernel I built is not the official RedHat release. Also
noted that 2.4.7 is not Redhat's latest release, either. If Carl Rodrigues
wishes to use official RedHat kernels in his testing of gcc 3.x, then perhaps
he should look at 2.4.19-21 or later.

As for the comment that the Linux kernel is somehow not a good enough test for
gcc 3.x, all interested parties (gcc hackers as well as kernel hackers) should
have a keen interest in how the Linux kernel compiles and executes under the
latest gcc. It behooves both sides to clean up both their acts or run the risk
of being left behind.

----- Original Message -----
From: "Jan Hubicka" <jh@suse.cz>
To: "Joseph S. Myers" <jsm28@cam.ac.uk>
Cc: "Christoph Hellwig" <hch@caldera.de>; "Toon Moene"
<toon@moene.indiv.nluug.nl>; "Craig Rodrigues" <rodrigc@attbi.com>;
<gcc@gcc.gnu.org>
Sent: Saturday, March 16, 2002 5:26 PM
Subject: Re: gcc 3.1 fails to build Linux 2.4.7 kernel on i686-linux


> > On Sat, 16 Mar 2002, Christoph Hellwig wrote:
> >
> > > > Then how could the linux-2.4.0.tar.gz kernel source end up in the
> > > > release criteria of GCC-3.1 ?
> > >
> > > I think that's a very bad choice.  Linux is know for abusing
> > > undocumented gcc features and having compiping an ancient kernel source
> > > tree as release criteria will never allow gcc to progress.
>
> I believe kernel has been choosen as one of most important software projects
> compiled by gcc.  It appears to be good test stressing some aspects of gcc
> others don't.
> > >
> > > Having a _current_ kernel appear in the release criteria might make
> > > sense, and even that only with enough cooperation from us kernel folks.
> >
> > 2.4.0 is in the 3.1 criteria because they were copied from the 3.0
> > criteria, and the Release Manager and SC still need to overhaul them to
> > reflect current intent properly.  Note that the top of that page says:
> >
> >    This document is still in its larval stage, and should not yet be
> >    taken as canonical. Most of the text is only a placeholder.
> >
> > 2.4.0 is in the 3.0 criteria because they had listed 2.2.14 (current
> > stable kernel when they were written), but once 2.4 was released it seemed
> > more appropriate than a 2.2 kernel to expect to compile with a new GCC.
> >
> > In practice this part of the release criteria didn't seem to get applied
> > for 3.0 - there weren't any regular status reports before the release
> > collecting details of what worked on what platforms, and what needed to be
> > made to work before release, and Linux 2.4.x compilation with 3.0.y didn't
> > work until about 3.0.3.
>
> Concerning the current state, I believe it is the 2.4.18 that first compiles
> with gcc 3.1 w/o problems.  I am just using 3.1 compiled kernel and noticed
no
> problem.  There has been few bugs.
> I even compiled working kernel with -mregparm=3 some time ago, but it has
> been patched slightly as previous kernels didn't compile cleanly.
>
> I guess we should just put 2.4.18 in the criteria and update it of more
> kernel bugs comes and gets fixed later.
>
> Honza
> >
> > --
> > Joseph S. Myers
> > jsm28@cam.ac.uk