2.2.0 and egcs 1.1 was Re: Sorry, wrong gcc-version

Andi Kleen (ak@muc.de)
25 Oct 1998 15:22:43 +0100


In article <ABYmoCsee0@khim.mccme.ru>,
"Khimenko Victor" <khim@sch57.msk.ru> writes:
> 25-Oct-98 00:06 you wrote:
>> you mean that definitely it is not a good idea to compile the kernel
>> with egcs-1.1b ??? then should i stick to my egcs-1.03 version that i
>> think has done well compiling kernels or which gcc version is the best ???

> 2.1.1xx (and thus 2.2) are just fine with egcs 1.1b (or at least if sometheing
> works ok with gcc 2.7.2.x and not with egcs 1.1b it's considered as bug :-)
> while 2.0.x MUST be compiled with gcc 2.7.2.1 or gcc 2.7.2.3 -- no other
> compilers allowed! If you want stable kernel that is (and why will you use
> 2.0.x if you do not want stable kernel? use 2.1.1xx instead!).

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. There was a patch from Bernd Schmidt to fix
that, but it didn't get included. Using egcs 1.1 is more risky than egcs 1.0,
because 1.1 optimizes more aggressively (e.g. it has an additional global CSE
pass which moves code around). The main difference between 2.0 and 2.1
regarding egcs is that the "obvious" bugs - like miscompiling sys_iopl which
breaks X11 - are fixed, but the more subtle ones remain: for example
the asm-i386/string.h functions are probably miscompiled in most situations,
but that doesn't show because only a few drivers exercise them completely.

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

Known Issues that still need to be fixed in 2.1 AFAIK:
- Bernd Schmidt's big asm constraints patch needs to be added.
- Some of the more complex inline string functions in asm-i386/string.h
probably need to be replaced by C only versions (should be ok because
things like strtok are not performance critical at all)
- The arch/i386/lib/checksum.c function needs to be converted to 100%
assembler.
- For egcs 1.1 -fno-gcse per default might be a good choice - there is just
too much risk that there are still a few barrier()s missing and with GCSE
the compiler is much more aggressive at moving code around. In my experience
at least in egcs 1.1 it generates faster and smaller code too because
of the decreased register pressure on x86 (egcs 1.1 doesn't seem to be well
tuned for x86 in this regard).

Linus what is your position on egcs 1.1 and 2.2.0 ?

-Andi

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