login
Search
Adrian Bunk posted a patch to the lkml to remove support for older versions of the Gnu Compiler Collection. With his patch, versions of gcc prior to 3.2 [story] would no longer be able to compile the kernel. He offers two advantages, "reducing the number of supported gcc versions from 8 to 4 allows the removal of several #ifdef's and workarounds", and "my impression is that the older compilers are only rarely used, so miscompilations of a driver with an old gcc might not be detected for a longer amount of time". He further explains, "my personal opinion about the time and space a compilation requires is that this is no longer that much of a problem for modern hardware, and in the worst case you can compile the kernels for older machines on more recent machines."
Public reactions to the proposition were entirely negative. David Miller explained that, "many people still use [gcc] 2.95 because it's still the fastest way to get a kernel build done and that's important for many people." Dave Airlie noted that some Linux kernel ports such as Linux on VAX don't even compile with the newer versions of the compiler. Others added that even if the kernel does compile with the latest gcc releases, they hit strange runtime errors not hit when compiling with an older version of gcc. It is apparent from this thread that support for at least gcc 2.95 is very unlikely to go away any time soon.
From: Adrian Bunk [email blocked]
To: Andrew Morton [email blocked]
Subject: [2.6 patch] remove support for gcc < 3.2
Date: Mon, 1 Aug 2005 00:26:07 +0200
This patch removes support for gcc < 3.2 .
The advantages are:
- reducing the number of supported gcc versions from 8 to 4 [1]
allows the removal of several #ifdef's and workarounds
- my impression is that the older compilers are only rarely
used, so miscompilations of a driver with an old gcc might
not be detected for a longer amount of time
My personal opinion about the time and space a compilation requires is
that this is no longer that much of a problem for modern hardware, and
in the worst case you can compile the kernels for older machines on more
recent machines.
This patch does not yet remove all the #ifdef's and other things that
are now no longer required, it only let's the compilation #error for
older gcc versions and updates the documentation.
I'd like to see this patch in the next -mm, and if noone will tell a
strong reason for keeping support for these gcc versions I'll send the
cleanups that are now.
[1] support removed: 2.95, 2.96, 3.0, 3.1
still supported: 3.2, 3.3, 3.4, 4.0
Signed-off-by: Adrian Bunk [email blocked]
---
Documentation/Changes | 23 ++---------------------
README | 6 +++---
include/linux/compiler.h | 4 +---
3 files changed, 6 insertions(+), 27 deletions(-)
--- linux-2.6.13-rc4-mm1/include/linux/compiler.h.old 2005-07-31 19:07:34.000000000 +0200
+++ linux-2.6.13-rc4-mm1/include/linux/compiler.h 2005-07-31 19:08:24.000000000 +0200
@@ -40,10 +40,8 @@
#error no compiler-gcc.h file for this gcc version
#elif __GNUC__ == 4
# include <linux/compiler-gcc4.h>
-#elif __GNUC__ == 3
+#elif (__GNUC__ == 3 && __GNUC_MINOR__ >= 2)
# include <linux/compiler-gcc3.h>
-#elif __GNUC__ == 2
-# include <linux/compiler-gcc2.h>
#else
# error Sorry, your compiler is too old/not recognized.
#endif
--- linux-2.6.13-rc4-mm1/README.old 2005-07-31 19:11:01.000000000 +0200
+++ linux-2.6.13-rc4-mm1/README 2005-07-31 19:11:38.000000000 +0200
@@ -174,9 +174,9 @@
COMPILING the kernel:
- - Make sure you have gcc 2.95.3 available.
- gcc 2.91.66 (egcs-1.1.2), and gcc 2.7.2.3 are known to miscompile
- some parts of the kernel, and are *no longer supported*.
+ - Make sure you have gcc >= 3.2 available.
+ Older versions of gcc are *no longer supported*.
+
Also remember to upgrade your binutils package (for as/ld/nm and company)
if necessary. For more information, refer to Documentation/Changes.
--- linux-2.6.13-rc4-mm1/Documentation/Changes.old 2005-07-31 19:11:56.000000000 +0200
+++ linux-2.6.13-rc4-mm1/Documentation/Changes 2005-07-31 19:12:48.000000000 +0200
@@ -48,7 +48,7 @@
hardware, for example, you probably needn't concern yourself with
isdn4k-utils.
-o Gnu C 2.95.3 # gcc --version
+o Gnu C 3.2 # gcc --version
o Gnu make 3.79.1 # make --version
o binutils 2.12 # ld -v
o util-linux 2.10o # fdformat --version
@@ -75,26 +75,7 @@
---
The gcc version requirements may vary depending on the type of CPU in your
-computer. The next paragraph applies to users of x86 CPUs, but not
-necessarily to users of other CPUs. Users of other CPUs should obtain
-information about their gcc version requirements from another source.
-
-The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it
-should be used when you need absolute stability. You may use gcc 3.0.x
-instead if you wish, although it may cause problems. Later versions of gcc
-have not received much testing for Linux kernel compilation, and there are
-almost certainly bugs (mainly, but not exclusively, in the kernel) that
-will need to be fixed in order to use these compilers. In any case, using
-pgcc instead of plain gcc is just asking for trouble.
-
-The Red Hat gcc 2.96 compiler subtree can also be used to build this tree.
-You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build
-the kernel correctly.
-
-In addition, please pay attention to compiler optimization. Anything
-greater than -O2 may not be wise. Similarly, if you choose to use gcc-2.95.x
-or derivatives, be sure not to use -fstrict-aliasing (which, depending on
-your version of gcc 2.95.x, may necessitate using -fno-strict-aliasing).
+computer.
Make
----
From: David S. Miller [email blocked]
Subject: Re: [2.6 patch] remove support for gcc < 3.2
Date: Sun, 31 Jul 2005 15:36:31 -0700 (PDT)
From: Adrian Bunk [email blocked]
Date: Mon, 1 Aug 2005 00:26:07 +0200
> - my impression is that the older compilers are only rarely
> used, so miscompilations of a driver with an old gcc might
> not be detected for a longer amount of time
Many people still use 2.95 because it's still the fastest
way to get a kernel build done and that's important for
many people.
And with 4.0 being a scary regression in the compile time
performance area compared to 3.4, this becomes even more
important to keep around.
From: Kurt Wall [email blocked]
Subject: Re: [2.6 patch] remove support for gcc < 3.2
Date: Sun, 31 Jul 2005 23:01:45 -0400
On Mon, Aug 01, 2005 at 12:26:07AM +0200, Adrian Bunk took 109 lines to write:
> This patch removes support for gcc < 3.2 .
>
> The advantages are:
> - reducing the number of supported gcc versions from 8 to 4 [1]
> allows the removal of several #ifdef's and workarounds
> - my impression is that the older compilers are only rarely
> used, so miscompilations of a driver with an old gcc might
> not be detected for a longer amount of time
>
> My personal opinion about the time and space a compilation requires is
> that this is no longer that much of a problem for modern hardware, and
> in the worst case you can compile the kernels for older machines on more
> recent machines.
Environments that require kernel compilation, often multiple times,
testing, benefit from shorter compile times. It can be the difference
between, say, completing a test suite overnight instead of having to
wait until tomorrow afternoon. Keeping 2.95, at least, has some value
in such environments.
Kurt
--
A chubby man with a white beard and a red suit will approach you soon.
Avoid him. He's a Commie.
From: Dave Airlie [email blocked]
Subject: Re: [2.6 patch] remove support for gcc < 3.2
Date: Thu, 4 Aug 2005 11:34:27 +1000
On 8/1/05, Adrian Bunk [email blocked] wrote:
> This patch removes support for gcc < 3.2 .
>
> The advantages are:
> - reducing the number of supported gcc versions from 8 to 4 [1]
> allows the removal of several #ifdef's and workarounds
> - my impression is that the older compilers are only rarely
> used, so miscompilations of a driver with an old gcc might
> not be detected for a longer amount of time
>
>
Another disadvantage is you'll really piss of the VAX developers (all
3 of us!!!, well me not so much anymore...)
I think there is a gcc 4.x compiler nearly capable of building a
kernel for the VAX...
Dave.
Continuity
Maybe the best solution would be to release the newer kernels without the support for the old complilers but to continue maintaining the support as a patch. If it turns out that the patch is extensively used, it can always be put back into the main tree.
Actually, that is the way new stuff is put into the kernel. Stuff enters as a patch and maybe it should also leave as a patch.
Just an idea.
Too hard to maintain as such,
Too hard to maintain as such, not worth it. It's a way bigger pain to remove it and maintain it as a patch, that it is to keep it in, and write patches to improve support on newer gcc's.
I don't really understand why people complain about compile times, sure it's nice when it's quick, but it's far from critical.
But then again there aren't r
But then again there aren't really important reasons for removing older gcc support afaics
Test cycle length
You aren't compiling and recompiling the same stuff over and over again. I tell you, the compile time speed is absolutely huge boon for everyone who developes with compiled languages doing the change-compile-test cycle.
tcc
If compilation speed is an issue, you can always use TCC http://tinycc.org/
This isn't really an option
TCC is an unoptimizing compiler. The only reason to use it is if compilation time is the _only_ factor.
Since people who build the kernel constantly probably want a kernel that would be usable in a real environment, an optimizing compiler is required.
Distribute it [the compilation]
Ok,
how about distcc?
http://distcc.samba.org/
It's what I've been using to get Gentoo working on my Pentium2 laptop.
I combined Distcc with Ccache
I combined Distcc with Ccache for my development, it goes pretty fast now.
Unoptimizing
TinyCC is not non-optimizing. As stated on the homepage (http://fabrice.bellard.free.fr/tcc/), "tcc generates optimized x86 code."
TCC-compiled kernels are completely usable, as even an unoptimized kernel still doesn't present a substantial overhead on modern machines.
Of course, I'm a big fan of ISO C99 for all concerned, but in practice nobody codes it and nobody can compile it.
is it?
Why does tcc's page say that it is an optimizing compiler?
it generates the sort of code
it generates the sort of code that a novice assembler programmer would write, rather than the absolute rubbish gcc produces at -O0.
Compilation times on old HW.
It's slighty annoying that when you debug a HW problem on your 40 MHz 840AV, takes 14 yours before you can test.
Such changes can mean the difference between one and two compile-test iterations per day instead of one.
Stupendous !!!
Hey !!
Apart from the '2.95 is fast' reason as well as the '2.95 still the best of the versions' reason for GCC, I believe the most important reasons are:
1. The 3.x series is not as stable (or as efficient) as the 2.95 series even now. (And we can obviously leave 4.x series out of the question).
2. The main reason for the new development model at the Kernel front was mainly because developing two separate branches was becoming more and more difficult. So a 'patch' system is a futile effort and extremely resource hungry too.
3. A lot of the smaller systems still depend heavily on the so called 'older' GCC versions. Frankly, I believe that for them the latest version of GCCs are almost out of reach. Then this form of split development is almost as if you are to exclude them.
And of course other reasons that others must have pointed out...
robins
Hrmm..
Wonder how much extra poking would be needed to keep support for 2.95, but drop support for everything from there to 3.2. From my own (lousy) memory, 3.0 and 3.1 had some bugs that required working around, that may not be required for 3.2+, and were not required for 2.95 either.
That way, all the 2.95 people would be happy, and we still lose cruft from the kernel.
Remember: Supported versions don't necessarily have to be X.Y and up.