> HB> [...]
> >> And here we have MAJOR problem: there are NO easy replacements for
> >> some such things used in linux kernel. Yes, it's not portable but
> >> what's can be done ? EVEN if kernel is broken just stating that "such
> >> code is not portable and so it's not our problem" is NOT ENOUGH. Some
> >> workaround is needed. And workaround without speed loss and supported
> >> on all supported platforms !
> HB> Sorry, I can't agree here. If you are fooling around with operating systems
> HB> (those things usually depend intimately on the hardware they run on), a
> HB> certain amount of pain caused by non-portability at the source level has to
> HB> be taken into account.
> Of course ! No arguments here. But if changes in egcs trigger some problems
> them some way to change sources MUST be provided.
>
> Typical discussion between Linus and egcs folks:
>
> Linus: "Egcs x.y.z miscompiles (does not allow, etc.) the following
> consturiction: <construction>".
> Egcs-folks: "<construction> is wrong in first place and should not work at
> all; it worked with gcc 2.7.2.3 by coincident".
> Linus: "No problems, I'm linux kernel guru, not egcs/gcc-guru. What's the
> correct replacement for <construction> in egcs x.y.z ?"
> Egcs-folks: "<construction> was wrong in first place and there are no
> replacement in egcs x.y.z"
> Linux: "<construction> WORKED with gcc 2.7.2.3. In DOES NOT work with egcs
> x.y.z . What's the replacement ?"
> Egcs-folks: "<construction> was wrong in first place and there are no
> replacement in egcs x.y.z"
This is a caricature. What has happened a few times was something along the
lines:
LT: <construction> doesn't work. It used to work with 2.7.2
ET: Yes, sorry. That was a bug in 2.7.2, the code is broken.
LT: Reenable!
ET: You'll have to rewrite, sorry. This is _not_ a compiler just for the
Linux kernel
It just so happens that the kernel is _the_ code that most streches the
compiler, AFAIK. Breakage due to ill-understood features, usage of outright
compiler bugs and reliance on optimizations done a certain way (or not
done) does happen.
Look at it from another perspective: There are lots of features for which
Linux enthusiasts are clamoring, and Linus (and the other head hackers
agree!) just doesn't allow them into the kernel. Quite rightly so, the
overwhelming mayority of the time. The egcs team is doing exactly the same,
to them the kernel is just _one_ more client among many thousands. An
important one, but in no way in a position to dictate egcs policy. And that
is also fine with me.
You'll have to live with that.
> This is UNAPPROPRIATE ! EVEN if construction was wrong and worked (on just
> a few millions of computers :-) by coincident it's not excuse to not give
> any replacement at all !
There have been replacements. Sometimes painful. OTOH, nobody is forcing
you to use gcc-2.95, are they?
> P.S. There are sometimes need to replace some constructions with
> different ones but it's not a problem: as you rightfully noted it's
> expected pain. Scenario described above -- that's why Linus is so angry
> on egcs folks ... Linus is willing to change kernel sources to accomodate
> changes in egcs. He just not ready to scan egcs sources to find a
> replacement ... He is linux kernel guru, not egcs/gcc guru ...
Fine. Let others do the grunt work (Alan Cox was instrumental in getting
linux to compile with egcs; I did my bit too, there were/are many others)
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/