Re: support of older compilers

Re: support of older compilers

[Xose Vazquez Perez]

Linus Torvalds wrote:

> Your "use new versions of gcc even if it is slower" argument doesn't make 
> any _sense_. If the new versions aren't any better, why would you want to 
> use them?

Maybe because older gccs are not maintained, only 3.3.x 3.4.x and 4.0.0.

_Unless_ you have a long life time distribution (aka SLES, RHEL or clones).

--
TLOZ OOT: worse than drugs.

Re: support of older compilers

[Anton Ertl]

Linus Torvalds:
>
>
>On Fri, 5 Nov 2004, Chris Wedgwood wrote:
>
>> On Fri, Nov 05, 2004 at 07:41:03AM -0800, Linus Torvalds wrote:
>> 
>> > > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
>> > > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
>> 
>> > Ok, you da man. What do you use it for? Or is it just lying around
>> > for nostalgic reasons?
>> 
>> to remind us how large the kernel is getting? :)
>
>Yeah, I know. Damn, it's scary. We should probably have some
>per-object-file statistics, and try to make people more aware of big bad
>things.

I can't offer that, but at least some more historic data on kernels
for my machines:

[~:42349] ls -ltr /boot|grep linu
...    231940 Mar 15  1994 vmlinux              #1.0
...    219652 Jul 19  1994 vmlinux_ethernet     #1.0
...    265188 Dec  7  1994 vmlinux-1.1.59-net
...    273380 Mar 29  1995 vmlinux-1.2.1
...    273412 Jun  4  1995 vmlinux-1.2.9
...    293892 Oct 26  1995 vmlinux-1.2.9-idecd
...    281604 Dec  9  1995 vmlinux-1.2.13
...    310276 May  9  1996 vmlinux-1.2.13-scsi
...    330756 Oct 30  1996 vmlinux-1.2.13-scsi-sound
...    446281 Dec  8  1997 vmlinuz-2.0.32-rh5.0
...    425237 Dec 20  1997 vmlinuz-2.0.32
...    381607 Jun 24  1998 vmlinuz-2.0.34
...    358407 Jul  3  1998 vmlinuz-2.0.34-2
...    480144 Sep 22  1998 vmlinuz-2.1.122
...    452853 Feb  9  1999 vmlinux-2.2.1
...    617431 May  8  1999 vmlinuz-2.2.5-15
...    721343 Dec 18  1999 vmlinuz-suse
...    500762 Jan 26  2000 vmlinux-2.2.14
...    728255 Nov 28  2000 vmlinux-2.4.0-test11
...    737572 Jun  3  2001 vmlinux-2.4.0-test11-cdrw
...    737575 May 10  2002 vmlinux-2.4.0-test11-usb
...    811903 Sep 26  2002 vmlinux-2.4.19
...   1330830 Nov 27  2003 vmlinux-2.4.21-suse
...   1270508 Nov 29  2003 vmlinuz-2.4.20-bf2.4
...   1322073 Feb 18  2004 vmlinuz-2.4.22-1.2174.nptl
...   1099371 Apr  4  2004 vmlinuz-2.4.25-amd64-nonetfilter
...   1101157 Apr  4  2004 vmlinuz-2.4.25-amd64
...   1062450 Apr  4  2004 vmlinuz-2.4.25-i386
...   1052249 Apr 13  2004 vmlinuz-2.4.25-i386-noagp
...   1068566 Apr 18  2004 vmlinuz-2.4.25-amd64-20040418
...   1017406 Apr 29  2004 vmlinuz-2.4.26-amd64
...   1271027 May  4  2004 vmlinuz-2.6.5-amd64
...   1271488 May  9 20:15 vmlinuz-2.6.5-amd64-20040509

I also still have a number of them in my LILO menu that probably don't
work:-)

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

Re: support of older compilers

[Clayton Weaver]

>You found a compiler bug, so you reported
>it as a bug against
>glibc?

You don't think it's possible that a glibc bug
could cause unexpected behavior in a gcc that is
using the glibc libraries?

I assure you it is. gcc-2.95.3 failed compiling
file.c from strace-4.4.1 when running with glibc-2.3.2
as it's libc, while it compiles it just fine when
running with glibc-2.2.5 as it's libc. (I included
this information and the compile log in my bug
report to the linux distributor.)

I don't know whether glibc-2.3.2 *really*
had the bug or whether gcc-2.95.3 had some
dodgy workaround for a bug in earlier glibc2
versions that fixing a bug in glibc-2.3.2
then exposed. Or if any of the glibc vendor
patches were involved (something that should
probably be sorted out before deciding to
file the bug report to gcc-bug@, so as not
to unnecessarily waste the time of gcc
maintainers).

Anyway, that's kind of beside the point.
It was merely an example of how a user
might come to decline an "obvious" gcc upgrade.

I guess what I was trying to say is that users
compiling the kernel with older gcc versions is
less a function of user perversity in refusing to
modernize their tools than it is a result of focus.

What problem is the user trying to solve while
using linux? Solving problems usually requires
eliminating variables that may present obstacles
to arriving at a solution, whether that solution
is working production code, some statistical result,
a document that displays correctly, correctly routed
network flows, whatever.

So users arrive at a relatively stable compiler,
they stop upgrading and use that. They find a
kernel that stays up for a week with no oops
reports or other wierdness, they use that. They
will periodically upgrade the compiler, libc,
kernel, etc, when they have a little spare time,
to take advantage of security fixes, new features,
better performance, whatever, *as long as the upgrade
does not become another variable in the problem that
the user is trying to solve*.

If it does turn out to be a variable (unstable
or in some other way unreliable), they toss it
and go back to the old version, because eliminating
variables until they arrive at the solution to their
problem is what they do. Any other method ends up
in combinatorial hell, and they never find a solution
to their problem except by luck.

Many are quite willing to test new versions, report
bugs, send in patches, etc, just to contribute, but
if their main focus is on other problems, they go back
to the  last stable version right away for their
everyday work.

This is not perverse, selfish, or uncooperative
behavior, it's merely normal problem-solving
methodology. On what basis would one expect
anything else from such a large user base?

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: support of older compilers

[Nix]

On 6 Nov 2004, Clayton Weaver stated:
>>You found a compiler bug, so you reported
>>it as a bug against
>>glibc?
> 
> You don't think it's possible that a glibc bug
> could cause unexpected behavior in a gcc that is
> using the glibc libraries?

Naturally it is; it's even fairly common if you're using a very old
compiler or a very old glibc (although support for libc5 is gone as of
GCC-3.4.)

> I don't know whether glibc-2.3.2 *really*
> had the bug or whether gcc-2.95.3 had some
> dodgy workaround for a bug in earlier glibc2
> versions that fixing a bug in glibc-2.3.2
> then exposed.

That's unlikely.

I just doubt that a bug in string concatenation could be chalked up to
glibc, is all.

> So users arrive at a relatively stable compiler, they stop upgrading
> and use that.

They're of course free to do that, if they don't mind not getting access
to new stuff in the new releases; at least if they're working in C
(anyone compiling C++ code with GCC<3.x is a little strange, in my
opinion).

-- 
`Random line noise picked up from an RS432 cable hung in front of a faulty
 radar transmitter. ' --- Greg Hennessy on sendmail.cf

Re: support of older compilers

[Clayton Weaver]

>If people are willing to download and compile
>a new kernel (and migrating from 2.4 to 2.6
>is non-trivial for some systems, like RH9),
>why aren't they willing to also download
>and build a new compiler?

It is not necessarily that they are unwilling,
it is a question of trust (in the output
of the compiler) and of the inconvenience of
multiple concurrent gcc version installations
(paths; hint: this needs to be simpler).

Example:

I've been using gcc-2.95.3 with a security-patched
glibc-2.2.5, and I wanted to upgrade to glibc-2.3.2
(lots of bugs gone and more Posix/SUS compliance
added in the years in between 2.2.5 and 2.3.2).

For that I needed gcc-3.x. So, in succession,
I downloaded and compiled gcc-3.3.2, 3.4.0, and 3.4.1,
against both glibc-2.2.5 and glibc-2.3.2, with the
latest binutils at the time (which works with any
of those compiler and glibc versions).

I found that none of the gcc 3.x versions could
correctly compile a construct like this
(independent of runtime glibc version):

file1.h:

/* header boilerplate to avoid multiple #includes of
   the same file */

#define STR1  "string 1"

file2.c:

#include "file1.h"

const char * str2 = "whatever"STR1"stuff this\n\
string has in it"STR1" and so on ad infinitum\n\
"STR1"yada yada"; 

/* this was actually about 40 lines, maybe more,
   with maybe 10 instances of "../"STR1"..." */

All of the gcc-3.x versions would bail with
an error trying to compile that str2 definition
in file2.c.

They didn't always fail on literal string
concatenation (IIRC some short ones compiled
ok), but they consistently failed to concatenate
literal strings correctly for some source
files that gcc-2.95.3 would compile correctly
every time.

(The glibc trees had distributor patches, so I filed
the bug report via their support, in order for
them to see whether their patches were responsible
for the error, assuming that they would forward
it on if not.)

In sum: for production code it doesn't matter
what all a new C compiler version can do that
the old one could not if it won't compile
quite ordinary standard C correctly.

"So what else is wrong with it that we
aren't seeing?"

It would be good to have bugs fixed in the
new compilers, because they obviously have
some advantages (I noticed that gcc-3.4.x
seemed quite a bit faster than 2.95.3 when
compiling glibc, and it would nice if as
no longer randomly choked on the x86 code
generated after using -fprofile-arcs and
-fbranch-probabilities, something that
occasionally happens with gcc-2.95.3).

But one does occasionally need to get some
other work done besides new compiler
development.

-- 
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

Re: support of older compilers

[Nix]

On 4 Nov 2004, Clayton Weaver stated:
> I found that none of the gcc 3.x versions could
> correctly compile a construct like this
> (independent of runtime glibc version):
> 
> file1.h:
> 
> /* header boilerplate to avoid multiple #includes of
>    the same file */
> 
> #define STR1  "string 1"
> 
> file2.c:
> 
> #include "file1.h"
> 
> const char * str2 = "whatever"STR1"stuff this\n\
> string has in it"STR1" and so on ad infinitum\n\
> "STR1"yada yada"; 
> 
> /* this was actually about 40 lines, maybe more,
>    with maybe 10 instances of "../"STR1"..." */
> 
> All of the gcc-3.x versions would bail with
> an error trying to compile that str2 definition
> in file2.c.

And do I see any bug reports from you in GCC bugzilla?  I do not (not
under the name `Clayton Weaver', anyway).

Further, the code you provide works in all the GCC-3.x versions I've got
here.

If you don't even *report* the bug, how can you expect it to get fixed?

> They didn't always fail on literal string
> concatenation (IIRC some short ones compiled
> ok), but they consistently failed to concatenate
> literal strings correctly for some source
> files that gcc-2.95.3 would compile correctly
> every time.

The preprocessor was totally rewritten between GCC-2.95.x and GCC-3.x: a
number of things that were valid in 2.95.x but invalid under ISO C were
made to not work in 3.x (for example, the compiler warns about attempts
to concatenate two things with ## that aren't preprocessing tokens, and
eventually this was made a hard error, IIRC).

This is, of course, not a bug.

I can find no mention of string concatenation bugs against the new
preprocessor relating to anything other than token pasting (and all of
those bugs are people trying to token-paste things that aren't tokens,
generally strings).

> (The glibc trees had distributor patches, so I filed
> the bug report via their support

What? You found a compiler bug, so you reported it as a bug against
glibc?

> In sum: for production code it doesn't matter
> what all a new C compiler version can do that
> the old one could not if it won't compile
> quite ordinary standard C correctly.

... especially if the people who see the problems don't report them and
don't provide reproducible testcases.

> It would be good to have bugs fixed in the new compilers,

It would be good if people would report bugs in the new compilers. :)

>                                                           because they
> obviously have some advantages (I noticed that gcc-3.4.x seemed quite
> a bit faster than 2.95.3 when compiling glibc,

It is quite a bit slower :(

-- 
`Preliminary analysis reveal there are few impact craters on Titan. This
 suggests Cassini has an active surface constantly being resurfaced.'
              --- BBC News Online introduces a new planetary body

support of older compilers

[Timothy Miller]

I'm just curious about why there seems to be so much work going into 
supporting a wide range of GCC versions.  If people are willing to 
download and compile a new kernel (and migrating from 2.4 to 2.6 is 
non-trivial for some systems, like RH9), why aren't they willing to also 
download and build a new compiler?

Re: support of older compilers

[Christoph Hellwig]

On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> I'm just curious about why there seems to be so much work going into 
> supporting a wide range of GCC versions.  If people are willing to 
> download and compile a new kernel (and migrating from 2.4 to 2.6 is 
> non-trivial for some systems, like RH9), why aren't they willing to also 
> download and build a new compiler?

Because the new compilers are a lot slower.

Re: support of older compilers

[Chris Wedgwood]

On Wed, Nov 03, 2004 at 09:13:53PM +0000, Christoph Hellwig wrote:

> Because the new compilers are a lot slower.

next you'll be claiming newer kernels are much larger than older
kernels (for similiar features)

Re: support of older compilers

[Adam Heath]

On Wed, 3 Nov 2004, Christoph Hellwig wrote:

> On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> > I'm just curious about why there seems to be so much work going into
> > supporting a wide range of GCC versions.  If people are willing to
> > download and compile a new kernel (and migrating from 2.4 to 2.6 is
> > non-trivial for some systems, like RH9), why aren't they willing to also
> > download and build a new compiler?
>
> Because the new compilers are a lot slower.

You can't be serious that this is a problem.

Re: support of older compilers

[Chris Wedgwood]

On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:

> You can't be serious that this is a problem.

try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
gcc was over twice as fast

Re: support of older compilers

[Adam Heath]

On Wed, 3 Nov 2004, Chris Wedgwood wrote:

> On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:
>
> > You can't be serious that this is a problem.
>
> try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
> gcc was over twice as fast

I didn't deny the speed difference of older and newer compilers.

But why is this an issue when compiling a kernel?  How often do you compile
your kernel?

Re: support of older compilers

[Chris Friesen]

Adam Heath wrote:

> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

You're posting to the kernel development list--many people here recompile dozens 
of times a day.

Chris

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004, Chris Friesen wrote:

> Adam Heath wrote:
>
> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you compile
> > your kernel?
>
> You're posting to the kernel development list--many people here recompile dozens
> of times a day.

So find the fastest computer you have, and use that.  There is no need to
compile a kernel on the machine it will be run on.

Re: support of older compilers

[Willy Tarreau]

On Thu, Nov 04, 2004 at 12:17:01PM -0600, Adam Heath wrote:
> > You're posting to the kernel development list--many people here recompile dozens
> > of times a day.
> 
> So find the fastest computer you have, and use that.  There is no need to
> compile a kernel on the machine it will be run on.

Uhh ?

What are you smoking ? We all have the fastest computers we can buy, and
since a kernel still takes a few minutes to compile on those computers,
we try to use the fastest compilers to save *HOURS* at the end of the day.
Nobody ever claimed that we all spend our time compiling on the target
system. I wonder if thas would be possible on a 16 MB/200 MHz MIPS ;-)

That's it.

Willy

Re: support of older compilers

[Geert Uytterhoeven]

On Fri, 5 Nov 2004, Willy Tarreau wrote:
> On Thu, Nov 04, 2004 at 12:17:01PM -0600, Adam Heath wrote:
> > > You're posting to the kernel development list--many people here recompile dozens
> > > of times a day.
> > 
> > So find the fastest computer you have, and use that.  There is no need to
> > compile a kernel on the machine it will be run on.
> 
> Uhh ?
> 
> What are you smoking ? We all have the fastest computers we can buy, and
> since a kernel still takes a few minutes to compile on those computers,
> we try to use the fastest compilers to save *HOURS* at the end of the day.
> Nobody ever claimed that we all spend our time compiling on the target
> system. I wonder if thas would be possible on a 16 MB/200 MHz MIPS ;-)

Why not? 16 MB and 200 MHz used to be plenty!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: support of older compilers

[Willy Tarreau]

On Fri, Nov 05, 2004 at 09:28:58PM +0100, Geert Uytterhoeven wrote:
> > Nobody ever claimed that we all spend our time compiling on the target
> > system. I wonder if thas would be possible on a 16 MB/200 MHz MIPS ;-)
> 
> Why not? 16 MB and 200 MHz used to be plenty!

Yes, sorry, I forgot to mention that instead of disk, I only have 8 MB
flash :-) Of course, I could do it over NFS, yes...

Cheers,
Willy

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 457 bytes --]

On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:

> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

If you're working on older hardware (note the number of people on this
list still using 500mz Pentium3 and similar), and a kernel developer, the
difference between 2 hours to build a kernel and 4 hours to build a
kernel matters quite a bit.

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004,  wrote:

> On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
>
> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you compile
> > your kernel?
>
> If you're working on older hardware (note the number of people on this
> list still using 500mz Pentium3 and similar), and a kernel developer, the
> difference between 2 hours to build a kernel and 4 hours to build a
> kernel matters quite a bit.

Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.

Plus, at least on i386/debian, kernel-package makes it easy.

Again, your argument doesn't hold water.

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Thu, 04 Nov 2004 12:15:47 CST, Adam Heath said:

> Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels
.

Hmm.. Send some faster hardware to Zwane then - I seem to recall
that his *faster* hardware was a 3-CPU 400mz box.

And then feel free to send faster hardware to everybody else on this
list who's not lucky enough to work for a company that will buy them
the latest-and-greatest.  For a lot of us, even a $700 consumer-class
machine is a major investment, and has to be balanced against things
like mortgages and food and keeping the car running so you can get to
your day job.....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004,  wrote:

> On Thu, 04 Nov 2004 12:15:47 CST, Adam Heath said:
>
> > Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels
> .
>
> Hmm.. Send some faster hardware to Zwane then - I seem to recall
> that his *faster* hardware was a 3-CPU 400mz box.

my home box is dual celeron 333.  If that machine can't keep up, then the make
system itself is buggy(and yes, I've written a complex automake-like
system(not released)).

Re: support of older compilers

[Ian Romanick]

Adam Heath wrote:
> On Thu, 4 Nov 2004,  wrote:
>>On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
>>
>>>I didn't deny the speed difference of older and newer compilers.
>>>
>>>But why is this an issue when compiling a kernel?  How often do you compile
>>>your kernel?
>>
>>If you're working on older hardware (note the number of people on this
>>list still using 500mz Pentium3 and similar), and a kernel developer, the
>>difference between 2 hours to build a kernel and 4 hours to build a
>>kernel matters quite a bit.
> 
> Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.
> 
> Plus, at least on i386/debian, kernel-package makes it easy.

And if that 500MHz Pentium3 *IS* they fastest hardware they have? 
Should they just go carjack someone to fund a new system to make you 
happy? ;)  Not everyone has a corporation like IBM or Redhat to fund 
their hardware needs.  A lot of people that make real, valuable 
contributions to lk are on a shoestring budget.

Re: support of older compilers

[Christoph Hellwig]

On Thu, Nov 04, 2004 at 12:15:47PM -0600, Adam Heath wrote:
> Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.

I think I have pretty fast hardware (e.g. dual g5 18.GHZ and P4 4.2 GHz),
and for me a kernel compile still takes far too long.

But if you want to buy me a 512p Altix and the electricity bill so I can
use gcc 3.3 all power  to you!

Re: support of older compilers

[Giuseppe Bilotta]

Christoph Hellwig wrote:
> On Thu, Nov 04, 2004 at 12:15:47PM -0600, Adam Heath wrote:
> > Use faster hardware to compile a kernel.  Cross-compiling is easy for kernels.
> 
> I think I have pretty fast hardware (e.g. dual g5 18.GHZ and P4 4.2 GHz),
> and for me a kernel compile still takes far too long.

Even on the 18 GHz system? :)

-- 
Giuseppe "Oblomov" Bilotta

Can't you see
It all makes perfect sense
Expressed in dollar and cents
Pounds shillings and pence
                  (Roger Waters)

Re: support of older compilers

[Willy Tarreau]

On Thu, Nov 04, 2004 at 07:48:24PM +0000, Christoph Hellwig wrote:
> But if you want to buy me a 512p Altix and the electricity bill so I can
> use gcc 3.3 all power  to you!

By the time it would be assembled, the 2048p they announced this week will
be available. Wait a few months Christoph ;-)

Willy

Re: support of older compilers

[Ian Hastie]

On Thursday 04 Nov 2004 17:04, Valdis.Kletnieks@vt.edu wrote:
> On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you
> > compile your kernel?
>
> If you're working on older hardware (note the number of people on this
> list still using 500mz Pentium3 and similar), and a kernel developer, the
> difference between 2 hours to build a kernel and 4 hours to build a
> kernel matters quite a bit.

How often is it necessary to do a full rebuild of the kernel?  If the 
dependencies in the make system work properly then only the amended parts 
should be recompiled.  That'd be a much bigger time saving than just using an 
older compiler.

-- 
Ian.

EOM

Re: support of older compilers

[Ioan Ionita]

Nobody mentioned that fact that newer versions of gcc, albeit slower
at compiling, do tend to generate binaries that have faster execution

On Thu, 4 Nov 2004 19:36:26 +0000, Ian Hastie <ianh@iahastie.clara.net> wrote:
> On Thursday 04 Nov 2004 17:04, Valdis.Kletnieks@vt.edu wrote:
> 
> 
> > On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
> > > I didn't deny the speed difference of older and newer compilers.
> > >
> > > But why is this an issue when compiling a kernel?  How often do you
> > > compile your kernel?
> >
> > If you're working on older hardware (note the number of people on this
> > list still using 500mz Pentium3 and similar), and a kernel developer, the
> > difference between 2 hours to build a kernel and 4 hours to build a
> > kernel matters quite a bit.
> 
> How often is it necessary to do a full rebuild of the kernel?  If the
> dependencies in the make system work properly then only the amended parts
> should be recompiled.  That'd be a much bigger time saving than just using an
> older compiler.
> 
> --
> Ian.
> 
> EOM
> 
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: support of older compilers

[Adrian Bunk]

On Thu, Nov 04, 2004 at 07:36:26PM +0000, Ian Hastie wrote:
> On Thursday 04 Nov 2004 17:04, Valdis.Kletnieks@vt.edu wrote:
> > On Thu, 04 Nov 2004 10:50:38 CST, Adam Heath said:
> > > I didn't deny the speed difference of older and newer compilers.
> > >
> > > But why is this an issue when compiling a kernel?  How often do you
> > > compile your kernel?
> >
> > If you're working on older hardware (note the number of people on this
> > list still using 500mz Pentium3 and similar), and a kernel developer, the
> > difference between 2 hours to build a kernel and 4 hours to build a
> > kernel matters quite a bit.
> 
> How often is it necessary to do a full rebuild of the kernel?  If the 
> dependencies in the make system work properly then only the amended parts 
> should be recompiled.  That'd be a much bigger time saving than just using an 
> older compiler.

As soon as you touch include files, a full recompile occurs pretty 
often because there are some include files pretty every other file 
depends on (and has to depend on).

Well, although I'm doing full kernel compiles sometimes several times a 
day I'm not that much addicted to compiler speed but I do understand 
others are.

> Ian.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

On Thu, 04 Nov 2004 19:36:26 GMT, Ian Hastie said:

> How often is it necessary to do a full rebuild of the kernel?  If the 
> dependencies in the make system work properly then only the amended parts 
> should be recompiled.  That'd be a much bigger time saving than just using an 
> older compiler.

Touch the wrong .h file, and 95% of the world still gets rebuilt. Similarly,
change the wrong CONFIG_ variable and thus the size/layout of a critical
structure, and watch 95% of the world still get rebuilt.


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Linus Torvalds]

On Thu, 4 Nov 2004, Adam Heath wrote:
>
> On Wed, 3 Nov 2004, Chris Wedgwood wrote:
> 
> > On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:
> >
> > > You can't be serious that this is a problem.
> >
> > try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
> > gcc was over twice as fast
> 
> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

First off, for some people that is literally where _most_ of the CPU 
cycles go.

Second, it's not just that the compilers are slower. Historically, new gcc 
versions are:
 - slower
 - generate worse code
 - buggier

For a _long_ time, the only reason to upgrade gcc was literally C++
support: basic C support was getting _worse_ with new compilers in pretty
much every regard.

Things seem to have improved a bit lately. The gcc-3.x series was 
basically not worth it for plain C until 3.3 or so.

		Linus

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004, Linus Torvalds wrote:

> > I didn't deny the speed difference of older and newer compilers.
> >
> > But why is this an issue when compiling a kernel?  How often do you compile
> > your kernel?
>
> First off, for some people that is literally where _most_ of the CPU
> cycles go.

So find a fast machine.  As I have already said, you don't need to compile a
kernel for a slow machine/arch *on* a slow machine/arch.

> Second, it's not just that the compilers are slower. Historically, new gcc
> versions are:
>  - slower

Again, that's a straw man.

>  - generate worse code
>  - buggier

I don't doubt these are issues.  That's not what I am discussing.

Re: support of older compilers

[Linus Torvalds]

On Thu, 4 Nov 2004, Adam Heath wrote:
> >
> > First off, for some people that is literally where _most_ of the CPU
> > cycles go.
> 
> So find a fast machine.  As I have already said, you don't need to compile a
> kernel for a slow machine/arch *on* a slow machine/arch.

I _have_ a fast machine. Others don't. And quite frankly, even I tend to 
prioritize things like "nice and quiet" over absolute speed.

> I don't doubt these are issues.  That's not what I am discussing.

Sure it is. You're complaining that developers use old versions of gcc. 
They do so for a reason. Old versions of gcc are sometimes better. They 
are better in many ways.

Your "use new versions of gcc even if it is slower" argument doesn't make 
any _sense_. If the new versions aren't any better, why would you want to 
use them?

		Linus

Re: support of older compilers

[Adam Heath]

On Thu, 4 Nov 2004, Linus Torvalds wrote:

>
>
> On Thu, 4 Nov 2004, Adam Heath wrote:
> > >
> > > First off, for some people that is literally where _most_ of the CPU
> > > cycles go.
> >
> > So find a fast machine.  As I have already said, you don't need to compile a
> > kernel for a slow machine/arch *on* a slow machine/arch.
>
> I _have_ a fast machine. Others don't. And quite frankly, even I tend to
> prioritize things like "nice and quiet" over absolute speed.
>
> > I don't doubt these are issues.  That's not what I am discussing.
>
> Sure it is. You're complaining that developers use old versions of gcc.
> They do so for a reason. Old versions of gcc are sometimes better. They
> are better in many ways.

Using an old version of gcc because it is faster at compiling is a
non-argument.  If people don't bother using newer compilers, complaining
about their inefficiencies, then the issues will never be resolved.

I have no problem with older gccs if they produce more correct code.

> Your "use new versions of gcc even if it is slower" argument doesn't make
> any _sense_. If the new versions aren't any better, why would you want to
> use them?

That's not my argument.  Never has been.  I am against people who say not to
use newer gccs only on the grounds that they are slower.

If they produce bad code, then that's a valid reason.
If they produce larger code, that is a valid reason.

But slowness doesn't mean wrong, just by being slow.

ps: it seldom makes sense to use a single metric as a measure of the quality
    of some specific item in some specific situation.

Re: support of older compilers

[Linus Torvalds]

On Thu, 4 Nov 2004, Adam Heath wrote:
> 
> But slowness doesn't mean wrong, just by being slow.

No.

"Right" and "wrong" have _nothing_ to do with anything.

he only thing that matters is "what is the best tool". And yes, 
performance _is_ an issue in selecting the best tool. It's not the only 
one, but it's a major one.

You said so yourself when you claimed people should just buy faster 
hardware. Again, the machine you use is just another tool. Why should you 
buy a faster machine if performance doesn't matter?

I don't understand why you first dismiss performance, and then go on to
ignore all the _other_ issues I told you about too.

And your argument about "things will get fixed if you use the newer
version" is also not actually true. First off, if it ain't broke in the 
older version, then things _literally_ will get fixed by not upgrading in 
the first place.

And telling a developer "I'm not using your new version because it sucks
compared to the old one" is actually a perfectly valid thing to do, and is 
likely to be _more_ motivational for the developer to get it fixed than 
having users that just follow the newest version like stupid sheep.

There are people out there using Linux-2.0. There are probably people even
using linux-1.2. And hey, that's OK. For older machines it may really be
the right choice, especially if they are still doing the same thing they
did several years ago. The notion that you somehow "have to" upgrade to
the newest version of software is BOGUS.

		Linus

Re: support of older compilers

[Andries Brouwer]

[Ob l-k]

I have not yet investigated, but my (vanilla) 2.6.9
has a mouse problem that my vanilla 2.6.8.1 does not have:
it starts selecting text as soon as I touch it for the first
time, as if the initialization created a fake mouse-down event.


[old stuff]

> There are probably people even using linux-1.2.

# uname -a
Linux knuth 1.2.11 #27 Sun Jul 30 03:39:01 MET DST 1995 i486

(486 DX/2, 66MHz, 8 MB)

-rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
-rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2


Andries

Re: support of older compilers

[Linus Torvalds]

On Fri, 5 Nov 2004, Andries Brouwer wrote:
>
> [Ob l-k]
> 
> I have not yet investigated, but my (vanilla) 2.6.9
> has a mouse problem that my vanilla 2.6.8.1 does not have:
> it starts selecting text as soon as I touch it for the first
> time, as if the initialization created a fake mouse-down event.

USB? We have another bug that was just root-caused to USB initialization 
sending a "clear suspend" packet, which apparently confuses some devices.

> [old stuff]
> 
> > There are probably people even using linux-1.2.
> 
> # uname -a
> Linux knuth 1.2.11 #27 Sun Jul 30 03:39:01 MET DST 1995 i486
> 
> (486 DX/2, 66MHz, 8 MB)
> 
> -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2

Ok, you da man. What do you use it for? Or is it just lying around for 
nostalgic reasons?

		Linus

Re: support of older compilers

[Arjan van de Ven]

On Fri, 2004-11-05 at 07:41 -0800, Linus Torvalds wrote:
> > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
> 
> Ok, you da man. What do you use it for? Or is it just lying around for 
> nostalgic reasons?

some people are just a bit stubborn in accepting elf binaries perhaps ;)

Re: support of older compilers

[linux-os]

On Fri, 5 Nov 2004, Arjan van de Ven wrote:

> On Fri, 2004-11-05 at 07:41 -0800, Linus Torvalds wrote:
>>> -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
>>> -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
>>
>> Ok, you da man. What do you use it for? Or is it just lying around for
>> nostalgic reasons?
>
> some people are just a bit stubborn in accepting elf binaries perhaps ;)

Most of the tools on this machine were built on this machine:

Script started on Fri 05 Nov 2004 11:02:59 AM EST
# ls -la
total 112
drwxr-xr-x   2 root root  4096 Nov  5 11:02 .
drwxr-xr-x  12 root root  4096 Oct 22  1997 ..
-rw-r--r--   1 root root  7433 Aug 23  1994 lpr.1
-rw-r--r--   1 root root 16776 Oct 22  1997 lpr.c
-rw-r--r--   1 root root 16614 Jul 29  1996 lpr.c~
-rw-r--r--   1 root root 16712 Nov 24  1996 lpr.c.orig
-rw-r--r--   1 root root 31948 Dec 17  1993 lpr.termios
-rw-r--r--   1 root root   188 Oct 25  1994 Makefile
# pwd
/home/project/usr/src/lpr-5.9/lpr
# exit
exit
Script done on Fri 05 Nov 2004 11:03:12 AM EST

I would modify the BSD source so it would compile and run
on Linux, then I would submit it. You can see, above that
`lpr` had to get modified in 1996 to accommodate some
changes (probably GCC changes).

I save all this to show that there isn't a GNU/Linux, really
a BSD/Linux.

Cheers,
Dick Johnson
Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
  Notice : All mail here is now cached for review by John Ashcroft.
                  98.36% of all statistics are fiction.

Re: support of older compilers

[Chris Wedgwood]

On Fri, Nov 05, 2004 at 07:41:03AM -0800, Linus Torvalds wrote:

> > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2

> Ok, you da man. What do you use it for? Or is it just lying around
> for nostalgic reasons?

to remind us how large the kernel is getting? :)

Re: support of older compilers

[Linus Torvalds]

On Fri, 5 Nov 2004, Chris Wedgwood wrote:

> On Fri, Nov 05, 2004 at 07:41:03AM -0800, Linus Torvalds wrote:
> 
> > > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
> > > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
> 
> > Ok, you da man. What do you use it for? Or is it just lying around
> > for nostalgic reasons?
> 
> to remind us how large the kernel is getting? :)

Yeah, I know. Damn, it's scary. We should probably have some
per-object-file statistics, and try to make people more aware of big bad
things.

The kernel does do more these days than it did in '95. But 6 times more? I 
dunno..

		Linus

Re: support of older compilers

[Grzegorz Kulewski]

> The kernel does do more these days than it did in '95. But 6 times more? I
> dunno..

Can't we remove ramfs for a good start? Everyone should use tmpfs instead 
and some stupid distributions (I will not tell their names) try to mount 
ramfs on /dev (udev) and that leads to very stupid panic if you will 
write for example:

dd if=/dev/evms/sda5 of=/dev/sda17 bs=1024

instead of "of=/dev/evms/sda17".

Explanation (if anybody needs one):
Kernel can't create more partition devices than 15 for SCSI and SATA disks 
because of lack of minor numbers. So I am using evms to create these 
devices. So I should use /dev/evms/sda* for these partitions. And if I 
will not remember to do so then I will get oom panic very shortly because 
ramfs is not limited (in contrary to tmpfs).

And this kind of stupid mistake can happen. It happened to me 3 times in a 
row before I started to debug what is wrong with this kernel.

[BTW. Does somebody know how to tell the kernel that I do not want 
/dev/sda[0-9]* files (but I do want /dev/hda files) created == I do not 
want kernel partition driver to touch this particular device?]

And using ramfs for anything else can easily lead to similar problems. So 
I think we do not need ramfs. Am I wrong? [I understand that removing it 
will not remove much code.]


Thanks,

Grzegorz Kulewski

Re: support of older compilers

[Linus Torvalds]

On Fri, 5 Nov 2004, Grzegorz Kulewski wrote:
> 
> And using ramfs for anything else can easily lead to similar problems. So 
> I think we do not need ramfs. Am I wrong? [I understand that removing it 
> will not remove much code.]

ramfs is very useful as a minimal filesystem for showing what the VFS
interfaces are, and also (I believe) used in embedded environments, where
it's simply the smallest possible thing, and swap isn't available anyway.

You can just disable it if you don't want it..

		Linus

RE: support of older compilers

[Hua Zhong]

At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
had to use ramfs. Has this been fixed?

> > The kernel does do more these days than it did in '95. But 
> 6 times more? I
> > dunno..
> 
> Can't we remove ramfs for a good start? Everyone should use 
> tmpfs instead 
> and some stupid distributions (I will not tell their names) 
> try to mount 
> ramfs on /dev (udev) and that leads to very stupid panic if you will 
> write for example:
> 
> dd if=/dev/evms/sda5 of=/dev/sda17 bs=1024
> 
> instead of "of=/dev/evms/sda17".
> 
> Explanation (if anybody needs one):
> Kernel can't create more partition devices than 15 for SCSI 
> and SATA disks 
> because of lack of minor numbers. So I am using evms to create these 
> devices. So I should use /dev/evms/sda* for these partitions. 
> And if I 
> will not remember to do so then I will get oom panic very 
> shortly because 
> ramfs is not limited (in contrary to tmpfs).
> 
> And this kind of stupid mistake can happen. It happened to me 
> 3 times in a 
> row before I started to debug what is wrong with this kernel.
> 
> [BTW. Does somebody know how to tell the kernel that I do not want 
> /dev/sda[0-9]* files (but I do want /dev/hda files) created 
> == I do not 
> want kernel partition driver to touch this particular device?]
> 
> And using ramfs for anything else can easily lead to similar 
> problems. So 
> I think we do not need ramfs. Am I wrong? [I understand that 
> removing it 
> will not remove much code.]
> 
> 
> Thanks,
> 
> Grzegorz Kulewski
> 
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: support of older compilers

[Willy Tarreau]

On Fri, Nov 05, 2004 at 02:08:45PM -0800, Hua Zhong wrote:
> At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
> had to use ramfs. Has this been fixed?

I believe it works now (2.4.27) but at least some external add-ons such as
Tux cannot serve pages on tmpfs but are OK on ramfs. What would be needed
is a ramfs with a size limit.

Willy

Re: support of older compilers

[Hugh Dickins]

On Sat, 6 Nov 2004, Willy Tarreau wrote:
> On Fri, Nov 05, 2004 at 02:08:45PM -0800, Hua Zhong wrote:
> > At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
> > had to use ramfs. Has this been fixed?

Yes, fixed in 2.4.22.

> I believe it works now (2.4.27) but at least some external add-ons such as
> Tux cannot serve pages on tmpfs but are OK on ramfs.

Oh, I thought that was fixed at the same time in 2.4.22.
Seems nobody complained it wasn't.  Probably easily done,
but really too late now to be adding features to 2.4.
The 2.6 tmpfs has no problem there, does it?

Hugh

Re: support of older compilers

[Willy Tarreau]

On Sat, Nov 06, 2004 at 09:43:57AM +0000, Hugh Dickins wrote:
> On Sat, 6 Nov 2004, Willy Tarreau wrote:
> > On Fri, Nov 05, 2004 at 02:08:45PM -0800, Hua Zhong wrote:
> > > At least in 2.4.17 I couldn't loopback mount an (ext2) image from tmpfs and
> > > had to use ramfs. Has this been fixed?
> 
> Yes, fixed in 2.4.22.
> 
> > I believe it works now (2.4.27) but at least some external add-ons such as
> > Tux cannot serve pages on tmpfs but are OK on ramfs.
> 
> Oh, I thought that was fixed at the same time in 2.4.22.
> Seems nobody complained it wasn't.  Probably easily done,
> but really too late now to be adding features to 2.4.

I don't understand what causes the problem, otherwise I would have been
happy to propose a patch.

> The 2.6 tmpfs has no problem there, does it?

I don't know. I essentially use tux as a target for network stress testing,
and since 2.6 is a lot slower in this area, I have not done extensive tests.

Cheers,
Willy

Re: support of older compilers

[Andries Brouwer]

# > > There are probably people even using linux-1.2.
# > 
# > # uname -a
# > Linux knuth 1.2.11 #27 Sun Jul 30 03:39:01 MET DST 1995 i486
# > 
# > (486 DX/2, 66MHz, 8 MB)
# > 
# > -rw-r--r--   1 root     root       281572 Jul 30  1995 zImage-1.2.11
# > -rw-r--r--   1 root     root       277476 Apr  1  1995 zImage-1.2.2
# 
# Ok, you da man. What do you use it for? Or is it just lying around for 
# nostalgic reasons?

One strength is the fact that it boots in a couple of seconds, while
my current 2.6.9 with vendor boot scripts takes minutes.
Another strength is the weight - exactly 2 kg.
I write letters, papers, lecture notes and stuff.
It feels faster than modern machines.
Only need X, TeX, emacs and rsh, rcp.

>> to remind us how large the kernel is getting? :)

> Yeah, I know. Damn, it's scary.
> The kernel does do more these days than it did in '95. But 6 times more?

I recall the times where 4K was enough for a multiuser OS that provided
each user its own virtual machine (and could run itself under itself).
Small is beautiful. Six times? Today for me is

-rw-r--r--  1 aeb users 3161708 2004-11-06 01:19 /boot/bzImage-2.6.9test

Probably I select more filesystems than you do.

Andries

Re: support of older compilers

[Linus Torvalds]

On Sat, 6 Nov 2004, Andries Brouwer wrote:
> 
> -rw-r--r--  1 aeb users 3161708 2004-11-06 01:19 /boot/bzImage-2.6.9test
> 
> Probably I select more filesystems than you do.

Ugh, you're right. Doing a reasonably normal build without modules nets us

	  205K mm/built-in.o                                            
	  336K kernel/built-in.o                                            
	  451K sound/built-in.o                                            
	  864K net/built-in.o                                            
	 1016K fs/built-in.o                                            
	  2.3M drivers/built-in.o                                            

which is kind of scary. Of course, in the drivers, about half a meg of
that is just the PCI name translation, so some of it is trivial (and
thrown away at boot), but most of it is just spread out in fat all over. 

It's hard to go on a diet.

		Linus

Re: support of older compilers

[Adrian Bunk]

On Sat, Nov 06, 2004 at 09:33:35AM -0800, Linus Torvalds wrote:
> 
> 
> On Sat, 6 Nov 2004, Andries Brouwer wrote:
> > 
> > -rw-r--r--  1 aeb users 3161708 2004-11-06 01:19 /boot/bzImage-2.6.9test
> > 
> > Probably I select more filesystems than you do.
> 
> Ugh, you're right. Doing a reasonably normal build without modules nets us
> 
> 	  205K mm/built-in.o                                            
> 	  336K kernel/built-in.o                                            
> 	  451K sound/built-in.o                                            
> 	  864K net/built-in.o                                            
> 	 1016K fs/built-in.o                                            
> 	  2.3M drivers/built-in.o                                            
> 
> which is kind of scary. Of course, in the drivers, about half a meg of
> that is just the PCI name translation, so some of it is trivial (and
> thrown away at boot), but most of it is just spread out in fat all over. 
> 
> It's hard to go on a diet.

It's even harder because some subsystem maintainers refuse to remove 
unused global functions that might be used at some point far in the 
future or that even are never intended for in-kernel usage...

> 		Linus

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: support of older compilers

[Willy Tarreau]

On Thu, Nov 04, 2004 at 05:39:08PM -0600, Adam Heath wrote:
 
> Using an old version of gcc because it is faster at compiling is a
> non-argument.

If you can send to all of us for free some hardware which is twice as fast
as what we have, which does not generate more heat and noise, then perhaps
most of us will accept to use a twice as slow compiler. But not for long,
since some may realize that they can produce quality code twice as fast on
their new system ;-)

At least, with fast machines and fast compilers, people have no excuse not
testing the patches they send. A few years ago, broken & non-tested patches
were very common. This could become standard again if everyone jumped into
gcc 3.4 unconditionnaly.

> If they produce bad code, then that's a valid reason.
> If they produce larger code, that is a valid reason.

You can also ask the gcc people when they will decide to write a new version
which is able to compile some code which compiles with the previous release.
I have some tools which don't compile anymore with gcc 3 and error messages
look more like insults than information, and I don't even know how to "fix"
(adapt ?) them. This too is a valid reason to stick to older compilers.

Willy

Re: support of older compilers

[Adam Heath]

On Fri, 5 Nov 2004, Willy Tarreau wrote:

> On Thu, Nov 04, 2004 at 05:39:08PM -0600, Adam Heath wrote:
>
> > Using an old version of gcc because it is faster at compiling is a
> > non-argument.
>
> If you can send to all of us for free some hardware which is twice as fast
> as what we have, which does not generate more heat and noise, then perhaps
> most of us will accept to use a twice as slow compiler. But not for long,
> since some may realize that they can produce quality code twice as fast on
> their new system ;-)
>
> At least, with fast machines and fast compilers, people have no excuse not
> testing the patches they send. A few years ago, broken & non-tested patches
> were very common. This could become standard again if everyone jumped into
> gcc 3.4 unconditionnaly.

My argument started when people starting complaining about new compilers being
slow, and using that as the only reason to not use them.

A single datapoint by itself can not be used in an argument here.

You are adding additional requirements(using older hardware), as that makes
the argument valid.

> > If they produce bad code, then that's a valid reason.
> > If they produce larger code, that is a valid reason.
>
> You can also ask the gcc people when they will decide to write a new version
> which is able to compile some code which compiles with the previous release.
> I have some tools which don't compile anymore with gcc 3 and error messages
> look more like insults than information, and I don't even know how to "fix"
> (adapt ?) them. This too is a valid reason to stick to older compilers.

Not always.  Older gccs accepted bad code; you can't honestly expect newer
ones to always accept this bad code.

Note: I'm not saying that's the specific case here.

Re: support of older compilers

[Martin J. Bligh]

>> > I didn't deny the speed difference of older and newer compilers.
>> > 
>> > But why is this an issue when compiling a kernel?  How often do you compile
>> > your kernel?
>> 
>> First off, for some people that is literally where _most_ of the CPU
>> cycles go.
> 
> So find a fast machine.  As I have already said, you don't need to compile a
> kernel for a slow machine/arch *on* a slow machine/arch.
> 
>> Second, it's not just that the compilers are slower. Historically, new gcc
>> versions are:
>>  - slower
> 
> Again, that's a straw man.
> 
>>  - generate worse code
>>  - buggier
> 
> I don't doubt these are issues.  That's not what I am discussing.

Ummm. you asked why people don't use newer compilers, you were told exactly
why. How is that not what you're discussing?

Not breaking older compilers takes very little effort in practice. Why the
hell would you want to break compilation with then?

M.

Re: support of older compilers

[Bill Davidsen]

Adam Heath wrote:
> On Wed, 3 Nov 2004, Chris Wedgwood wrote:
> 
> 
>>On Wed, Nov 03, 2004 at 05:06:56PM -0600, Adam Heath wrote:
>>
>>
>>>You can't be serious that this is a problem.
>>
>>try it, say gcc 2.95 vs gcc 4.0 ... i think last i checked the older
>>gcc was over twice as fast
> 
> 
> I didn't deny the speed difference of older and newer compilers.
> 
> But why is this an issue when compiling a kernel?  How often do you compile
> your kernel?

Twice for each -bk to look for "not my fault" issues (preempt and not), 
usually once with some combination of Nick, Con, or Ingo patches, and 
then with config options depending on what's been added. Not to mention 
patches I cull from here and my own set of network patches.

For some people I bet the limit is 24/{compile_time} per day.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: support of older compilers

[Martin J. Bligh]

>> On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
>> > I'm just curious about why there seems to be so much work going into
>> > supporting a wide range of GCC versions.  If people are willing to
>> > download and compile a new kernel (and migrating from 2.4 to 2.6 is
>> > non-trivial for some systems, like RH9), why aren't they willing to also
>> > download and build a new compiler?
>> 
>> Because the new compilers are a lot slower.
> 
> You can't be serious that this is a problem.

Yes, it is. Mostly they produce larger, slower code too.

M.

Re: support of older compilers

[Matti Aarnio]

On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> I'm just curious about why there seems to be so much work going into 
> supporting a wide range of GCC versions.  If people are willing to 
> download and compile a new kernel (and migrating from 2.4 to 2.6 is 
> non-trivial for some systems, like RH9), why aren't they willing to also 
> download and build a new compiler?


How about those other architectures, than i386 ?
Over the years I have learned, that while GCC may work OK in i386,
the same version used in SPARC does produce bad code.  This has
bitten me multiple times.


We weird people of other architechtures do tend to get "somewhat"
conservative over the years in finding, and finally staying with
a compiler that we have learned to work.   Multiple burned,
forever shy...

 /Matti Aarnio

Re: support of older compilers

[Giacomo A. Catenazzi]

Matti Aarnio wrote:
> On Wed, Nov 03, 2004 at 04:02:49PM -0500, Timothy Miller wrote:
> 
>>I'm just curious about why there seems to be so much work going into 
>>supporting a wide range of GCC versions.  If people are willing to 
>>download and compile a new kernel (and migrating from 2.4 to 2.6 is 
>>non-trivial for some systems, like RH9), why aren't they willing to also 
>>download and build a new compiler?
> 
> 
> 
> How about those other architectures, than i386 ?
> Over the years I have learned, that while GCC may work OK in i386,
> the same version used in SPARC does produce bad code.  This has
> bitten me multiple times.
> 
> 
> We weird people of other architechtures do tend to get "somewhat"
> conservative over the years in finding, and finally staying with
> a compiler that we have learned to work.   Multiple burned,
> forever shy...

But is it Linux the biggest compiler bug finder?
So forcing a newer compiler in other architectures should
improve also the quality of code generation.

ciao
	cate

Re: support of older compilers

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 543 bytes --]

On Wed, 03 Nov 2004 22:37:10 +0100, "Giacomo A. Catenazzi" said:

> But is it Linux the biggest compiler bug finder?
> So forcing a newer compiler in other architectures should
> improve also the quality of code generation.

However, the problem is that I probably want to compile a working
kernel *now*, not when the GCC people finally get around to fixing
the b0rkedness they added for my architecture in gcc 3.2.3.  So I
get to keep 3.2.2 around until it's fixed.  (Feel free to replace
3.2.3 with whatever arch-dependent value you like).


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: support of older compilers

[Miles Bader]

Valdis.Kletnieks@vt.edu writes:
> However, the problem is that I probably want to compile a working
> kernel *now*, not when the GCC people finally get around to fixing
> the b0rkedness they added for my architecture in gcc 3.2.3.

Yup, this is particuarly true with fringe architectures.

E.g., you're using a compiler for your CPU that has changes not in
mainstream gcc, the vendor who made them is slow in updating to new gcc
versions, and their changes are complex enough that you don't want to
spend the manpower to port them yourself.

You've got the GPL, so of course it's of course _possible_ to do the
work yourself and get a newer gcc working, but sometimes it's really
nice to also have the option _not_ to do that...

-Miles
-- 
((lambda (x) (list x x)) (lambda (x) (list x x)))

Re: support of older compilers

[Chris Wedgwood]

On Wed, Nov 03, 2004 at 10:37:10PM +0100, Giacomo A. Catenazzi wrote:

> But is it Linux the biggest compiler bug finder?

for C it might be, obviously not for C++

> So forcing a newer compiler in other architectures should
> improve also the quality of code generation.

assuming there are sufficiently many people to work on gcc and those
platforms (there isn't)