lkml.org 
[lkml]   [1998]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Egcs 1.0.3 & Linux


On Sun, 17 May 1998, Khimenko Victor wrote:

> 17-May-98 11:04 you wrote:
> > 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.
>
> Unfortunatelly "bug in source code" is VERY VERY week conception. Simple example:
>
> #include <stdio.h>
> int a=0;
> int f(void) { a=1;return 1; }
> void main(void) { printf("%d",f()+a); }
>
> Of course this code contains nasty bug and two compilers could generate two
> programs with different behaviour -- one will write 1 and other will write 2.
> I am know no copilers who will write error for such program (especially if
> a will be in one file while main() will be in second file). This is VERY simple
> example. So ... You are wrong. Even if code will not generate error and will
> work just fine while compiled with one compiler WITHOUT BUGS (in fact most
> compilers contains bugs but this is other story) could still does not work
> while compiled with other compiler WITHOUT BUGS! So you are wrong here: even
> if code is compiled bu compiler without bugs and works just fine still does
> not mean that code does not contains bugs! And looks like it's possible to
> prove that you could not write program able to catch all such bugs (this is
> not trivial task, unfortunatelly) ! Really this is exactly situation with egcs
> and kernel -- there are few known (and god knows how many unknown :-) places
> where egcs will generate wrong code since source code contans bugs like
> bug above... Most of them is cleaned out in 2.1.102 but noone knows -- how
> many still left there :-(( By the way I am using pgcc 1.0.2 for all compilations
> (including kernel, of course). I am not using 2.0.x kernels through ...

The extremely lucid point that Khimenko has made here is that the
response to "I compiled 2.1.102 with EGCS and now it doesn't boot
at all" is not "use GCC" or the ever popular "EGCS is buggy", but
should be "thanks for your bug report as it indicates there might
be some ambiguous code in the kernel".

It is foolhardy to ignore such bug reports: they could be perhaps
the most valuable bug reports possible. C is ambiguous, and it is
full of hidden traps like Khimenko's example shows. Using varying
C compilers is an excellent way of uncovering problems in Linux's
source tree that would otherwise remain hidden.



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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