Re: Egcs 1.0.3 & Linux

Michael H. Warfield (
Sun, 17 May 1998 11:04:07 -0400 (EDT)

Jordan Mendelson enscribed thusly:

> Just curious to know if Egcs 1.0.3 (released today @
> correctly compiles the Linux kernel.
> I'm not talking about "yes, I built it and it seems to run just fine after
> one hour". I want to know if it correctly generates code which will run the
> kernel correctly in all instances.

I would love to see someone come up with a method of demonstrating
anything of that sort. Should make him a fortune. Some sort of formal
proof that, "oh if you compile this, this will work for all instances", where
instances is a significant number of non-trivial conditions. Gee! It
would make software development, testing, and QA soooo much easier... :-)

> I've also been wondering if the problems with Egcs & GCC 2.8.x compiling the
> Linux kernel are bad kernel code or bad compiler code. It would seem to me
> that if it was a compiler problem, then it would be listed in the cavaets or
> bugs listings somewhere, but it isn't.

Receipe for rabbit stew: "First you catch a rabbit". A new release
comes out with certain known problems and an indeterminant number of possible
problems. Some problems crop up right away and are determinant as to where
and how to fix them. Some problems can't even be reproduced except under
conditions the authors either can't supply or can't determine. Would be a
neat trick to list all of the cavaets or bugs somewhere, but we have to
settle for SOME of the KNOWN cavaets and bugs. The simple ones often get
fixed faster than they can get listed. The ones that get listed are the
known ones which are going to take more work. One thing that won't be
in the cavaet's file (at least not the one in the tarball packages) is
anything uncovered after the release (when the file was written). Websites
can be different, but I don't know anyone who goes back and updates the
included cavaets or bugs files between releases. So what you've got are
just the bugs known at the point of release (unless you check a currently
bug list outside of the package).

Now... When you get in a situation like this... "Gee, I compiled
it with foo 1 and it works. When I compile it with foo 2 it's busted. When
I compile it with bar 1 it's busted". Is it the compilers or is it the
source code. Well... It depends. I would argue this though - even if it
is a bug in the source code, the fact that some compilers generated incorrect
code from that source without flagging an error, it indicates some sort of
bug in the compilers. They should either generate correct code or generate
an error. They should not generate incorrected code. But I've been working
with compilers since the 70's. They will be singing Jingle Bells in Hades
before we get to that day.

> GCC 2.8.x has been out for some time, so has Egcs, it's strange that no one
> has fixed the problems that plague compilation of Linux kernel.. probably
> one of the most recompiled things on the planet.

Maybe most of us are using earlier gcc's. RedHat 5.0 ships with
gcc I'm not inclined to go through the painful process of upgrading
a compiler without a REAL GOOD reason and the discussions over gcc 2.8 and
egcs are certainly good reasons not to.

> Jordan

> --
> Jordan Mendelson :
> Web Services, Inc. :


 Michael H. Warfield    |  (770) 985-6132   |
  (The Mad Wizard)      |  (770) 925-8248   |
  NIC whois:  MHW9      |  An optimist believes we live in the best of all
 PGP Key: 0xDF1DD471    |  possible worlds.  A pessimist is sure of it!

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to