Re: Egcs 1.0.3 & Linux

Khimenko Victor (
Sun, 17 May 1998 22:41:49 +0400 (MSD)

PB> Interesting point ...
PB> "A month of sundays ago Khimenko Victor wrote:"
PB> >
PB> > #include <stdio.h>
PB> > int a=0;
PB> > int f(void) { a=1;return 1; }
PB> > void main(void) { printf("%d",f()+a); }
PB> Of course this is really
PB> print (a=1)+a
PB> in disguise, and depends on the order of evaluation of expressions with
PB> side effects.
Yes. But some compilers will warn you about (a=1)+a all known to me will not
warn about program above.

PB> > Of course this code contains nasty bug and two compilers could generate two
PB> > programs with different behaviour -- one will write 1 and other will write 2.
PB> Indeed. Indeed the code is not in error.
PB> > if code is compiled bu compiler without bugs and works just fine still does
PB> > not mean that code does not contains bugs! And looks like it's possible to
PB> > prove that you could not write program able to catch all such bugs (this is
PB> You are asking if a compiler can detect when the defined semantics of the
PB> programming language does not assign a uniquely determined semantics to
PB> a given program? Durrrrrrrrrrrrr ... well if it could, then I could
PB> take any program A(x) and write the program A'[k];B, where B is your
PB> example program above and A'[k] is the version of A with all its printfs
PB> removed and an "x=k;" inserted at the beginning, so that it can't do
PB> anything except terminate or not.
PB> A'[k];B is a nondeterministic program precisely when A(k) halts (because
PB> B can be any of two things) and deterministic when A(k) does not halt
PB> (it does nothing). A compiler which correctly detected these two
PB> situations would be solving the halting problem for A(k), which is
PB> impossible for a machine.
Yes. But I am NOT TALKING about program "as whole". I am talking about
potential ambiguities. I.e. it's does not matter -- could be some code
executed or no. In this situation you could not use trick above.

PB> So no. No compiler can detect the ambiguities CORRECTLY. It can however
PB> warn you that you may have dangerous constructs around, and err on the
PB> side of caution. Or it may consistently ignore dangers like that. It
PB> must do one or the other.
C compiler could not do this is in A LOT OF cases. If you have f() in one file
and main in other compiler simple does not have enough information. If
compiler will warn about any + sign ... Hm. Thare are will be to many such
warnings: if (sin(x)+y) will generate warning... Hm.

PB> > not trivial task, unfortunatelly) ! Really this is exactly situation with egcs
PB> Trivial.
No. "Trivial" != "easily". We need a lot of definitions, etc to be able correcly
talks about question. Thus this is not trivial question.

PB> > and kernel -- there are few known (and god knows how many unknown :-) places
PB> > where egcs will generate wrong code since source code contans bugs like
PB> > bug above... Most of them is cleaned out in 2.1.102 but noone knows -- how
PB> > many still left there :-(( By the way I am using pgcc 1.0.2 for all compilations
PB> > (including kernel, of course). I am not using 2.0.x kernels through ...
PB> >
PB> Nice.

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