lkml.org 
[lkml]   [1998]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 2.2.0 and egcs 1.1 was Re: Sorry, wrong gcc-version
In <Pine.LNX.3.96.981025144701.3859K-100000@penguin.transmeta.com> Linus Torvalds (torvalds@transmeta.com) wrote:

LT> On 25 Oct 1998, Andi Kleen wrote:
>>
>> Actually this is not entirely correct. Even 2.1.x kernels still have lots
>> of incorrect inline assembler constraints which can cause the compiler
>> to misoptimize the kernel.

LT> I don't agree.

LT> The assembler used to be correct, and the gcc people unilaterally decided
LT> to change the rules.

It's their right to change rules. And now this assembler is incompatible with
egcs 1.1b (it's not "incorrect" since there are no standards for such assembler).
And thus should be fixed.

LT> As such, I don't think the asm is any more "incorrect" than the new gcc
LT> versions are incorrect.

No. There are exist some bugs in new gcc versions but it's not bug. It's
feature. Unpleasant and may be even useless feature, but feature, not bug.
On other side of course kernel is not "incorrect" as well. Just incompatible
with egcs 1.1b. And thus should be fixed.

LT> The changes I have seen break older compilers.

What about #ifdef's ? AFAIK it's only in processor-dependant parts of kernel
and this parts should be small (and little messy :-) anyway... This is only
temporarily solution anyway: you could not compile kernel 2.1.126 with
gcc 2.5.1 why 2.3.57 should be compilable with gcc 2.7.2.3 ???

LT> So Andi, don't go saying that the kernel has problems, when it is equally
LT> true to say that gcc has problems.

No. gcc does NOT have problems (at least here :-). gcc could be called buggy
if and ONLY if program written on pure ANSI C (or ANSI C++ is it's C++ compiler)
will be miscompiled (and thus C++ compiler in egcs STILL could be called buggy).
All above of ANSI C is good will of gcc (egcs) folks. And could be changed
"without prior nofications"... The same as with kernel and driver writers: you
could change iterface if you wish and driver writers must change drivers after
that. How many times it was done ? When suddenly some drivers is broken since
"Today Linus redesigns the networking driver interface" this means that
drivers must be rewritten even if this drivers was Ok for ages. Why situation
with gcc is other ?

>> In short, if you want to play safe stay with 2.7.2.3 for kernel compilation.

LT> That, I think, everybody can agree on.

Of course it's right. But this is not since kernel is buggy or egcs is buggy.
It's just means that kernel is not compatible with egcs and should be fixed.
Just as old network drivers are not buggy -- thay are just not compatible with
latest kernel and thus should be fixed... But usually such incopatibilities are
called "bugs" nevertheless...

>> Linus what is your position on egcs 1.1 and 2.2.0 ?

LT> My problem is that I see too many egcs people that claim that the kernel
LT> is buggy, even though at least half the reports I ever got were egcs bugs,
LT> in my opinion.

Once more: in my opinion gcc (or egcs) COULD be called "buggy" ONLY if it's
not ANSI-C compatible in ANSI C mode. All other bugs could be called so ONLY
if documetation and real behaviour differs. And in such cases it's gcc folks
choice what to fix: documentation or compiler.

LT> As such, I don't have very much faith in what the egcs people tell me any
LT> more.

Ok. Wording was chosen wrong. It was not bug's in kernel. It was incopatibilities
with egcs in IMPLEMETATION SPECIFIC parts of egcs.

LT> For example, everybody in the egcs camp just decided that clobbers and
LT> inputs must not overlap. Nobody told me why, and why they can't just be
LT> automatically converted to early-clobbers inside gcc.

And nobody SHOULD ! It's their right to make such decisions ! Yes, it's bad
when such rules are changed. Some essentional programs (like Linux kernel) must
be rewritten. And it's better to avoid such changes but it's egcs folks right
to do this.

LT> Because clobbers and inputs used to be the only way to do certain things
LT> in gcc, and now suddenly there's a witch-hunt going on against them.
LT> That's sad.

Yes, but eventually something should be done about this. It's unwise to stuck
with gcc 2.7.2.3 forever. For ordinal C programs and [especially] C++ programs
egcs 1.1b is by far less buggy compiler then gcc 2.7.2.3 and thus should be
preffered. Of course it's possible to keep old compiler just compile kernel
(for example quite a few programs in MS Windows98 was compiled with MS VC++ 1.52
which is not supported anymore; other example: few programs in Borland Pascal
was compiled with Turbo Pascal 3.01 even if Turbo Pascal 3.01 was not in stores
anymore for ages), but it's does not look like a good solution :-((





-
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/

\
 
 \ /
  Last update: 2005-03-22 13:45    [W:0.125 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site