Re: GCC speed (was [PATCH] Isapnp warning)

[John Bradford <john@grabjohn.com>]

> No.  Compilation inefficiency directly harms programmer efficiency and the
> quality and volume of code the programmer produces.  These are surely the
> most important things by which a toolchain's usefulness should be judged.
>
> I compile with -O1 all the time and couldn't care the teeniest little bit
> about the performance of the generated code - it just doesn't matter.
>
> I'm happy allowing those thousands of people who do not compile kernels all
> the time to shake out any 3.2/3.3 compilation problems.
>
>
> Compilation inefficiency is the most serious thing wrong with gcc.

Code for hardware that almost nobody has anymore isn't easily tested
for subtle compilation errors.

The math emulation code didn't even compile for a while, and that went
unnoticed.  IFF there are substantial benefits to dropping 2.95.3
should we risk drivers for things like obscure SCSI cards being
mis-compiled and randomly corrupting data.

There _must_ be hardware that nobody has tested a gcc 3 compiled
kernel on.

All 2.5.X trees, and most 2.4.x trees have had a _lot_ of testing with
GCC 2.95.3, in a lot of different environments.  Especially in the
case of 2.4.X, a lot of that code hasn't seen significant changes in
the last year or so, and those code paths have been shown to be very
stable with gcc 2.95.3.

Eliminating gcc 2.95.3 support when a lot of people are still using
it, and having a large number of users migrate to gcc 3.3 could
uncover subtle compiler bugs a month or two later, and we'd end up
having to either live with that, or add support for gcc 2.95.3 back
in.

John.