[2.6 patch] remove support for gcc < 3.2
Adrian Bunk
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 <bu...@stusta.de>
---
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
----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
David S. Miller
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.
Nigel Cunningham
On Mon, 2005-08-01 at 08:36, David S. Miller wrote:
> 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.
Yes, please don't remove 2.95 support.
Regards,
Nigel
--
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.
Kurt Wall
> 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.
Miles Bader
> This patch removes support for gcc < 3.2 .
Go away.
-miles
--
"Suppose He doesn't give a shit? Suppose there is a God but He
just doesn't give a shit?" [George Carlin]
Willy Tarreau
> 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.
I *do* still use 2.95 a lot, and I'm not alone, judging from people
around me. 2.95 has been the reference for a very long time, that's
why it's still so much present. 3.0 and 3.1 (even 3.2) have been
there for a very short time frame, but 2.95 and 3.3 really seem to
be references compilers.
So please keep support for 2.95.
Cheers,
Willy
Jan-Benedict Glaw
> 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
> [1] support removed: 2.95, 2.96, 3.0, 3.1
> still supported: 3.2, 3.3, 3.4, 4.0
This patch in mind, I built the vax-linux kernel again with gcc-HEAD
(gcc-4.1) and it blew off in:
$ make V=1 ARCH=vax CROSS_COMPILE=vax-linux- mopboot
[...]
vax-linux-gcc -Wp,-MD,init/.initramfs.o.d -nostdinc -isystem /home/jbglaw/vax-linux/scm/build-20050802-171439-vax-linux/install/usr/lib/gcc/vax-linux/4.1.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O1 -fomit-frame-pointer -pipe -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_BASENAME=initramfs -DKBUILD_MODNAME=initramfs -c -o init/initramfs.o init/initramfs.c
init/initramfs.c:10: error: message causes a section type conflict
init/initramfs.c:33: error: head causes a section type conflict
init/initramfs.c:80: error: ino causes a section type conflict
init/initramfs.c:80: error: major causes a section type conflict
[...]
Adding -fno-unit-at-a-time fixed this, but from what Google found, this
is actually a bug in the C sources: the __initdata variables are to be
put into a read-only segment but are missing a const qualifyer, so
-fno-unit-at-a-time seems to hide a bug here.
Could somebody comment on this? Or shall I open a bug report for GCC?
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de . +49-172-7608481 _ O _
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg _ _ O
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak! O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Gustavo Guillermo Pérez
> This patch removes support for gcc < 3.2 .
If you have old hardware with not much resources gcc 2.95 works just fi
ne and
fast, even you build the main kernel on other machine, by compatibility
issues one or two drivers should be builded a lot of times into the old
er
hardware, then we are forced to build gcc 3.4 or something like.
:(
--
Gustavo Guillermo Pérez
Compunauta uLinux
www.compunauta.com
Mathieu Chouquet-Stringer
> Please keep the 2.95 support I use to use a lot, on not new hardware.
> If you have old hardware with not much resources gcc 2.95 works just
ty
> issues one or two drivers should be builded a lot of times into the o
lder
> hardware, then we are forced to build gcc 3.4 or something like.
Moreover I get some weird networking problems which prevent setting up
the
routes (RNETLINK invalid argument messages) when I compile my kernel wi
th
4.0.1 while the same kernel, same config works fine compiled with 3.2.3
..
So eventhough 4.0 is supposed to be supported, it doesn't work too well
in
my case.
--
Mathieu Chouquet-Stringer
Dave Airlie
> 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.
Jan-Benedict Glaw
> On 8/1/05, Adrian Bunk <bu...@stusta.de> 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...
-sh-3.00# cat cpuinfo
cpu : VAX
cpu type : KA43
cpu sid : 0x0b000006
cpu sidex : 0x04010002
page size : 4096
BogoMIPS : 10.08
-sh-3.00# cat version
Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005
Current GCC from CVS (plus minor configury patches) seems to work. We
had -fno-unit-at-a-time missing in our arch Makefile which hides a bug
in kernel's sources.
I guess that if you remove -fno-unit-at-a-time from i386 and use a
current GCC, you'll run into that fun, too.
MfG, JBG
PS: Yes, we lie about page size.
Adrian Bunk
>...
> Current GCC from CVS (plus minor configury patches) seems to work. We
> had -fno-unit-at-a-time missing in our arch Makefile which hides a bug
> in kernel's sources.
>
> I guess that if you remove -fno-unit-at-a-time from i386 and use a
> current GCC, you'll run into that fun, too.
What bug exactly?
I'm sometimes using kernels compiled with gcc 4.0 and without
-fno-unit-at-a-time and except for the kernel image being smaller I
haven't noticed any difference. Besides this, all architectures except
i386 and um are not disabling unit-at-a-time.
There are a few parts of the kernel that might still have stack problems
with unit-at-a-time, but I assume that's not what you are talking about?
> MfG, JBG
>...
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
Adrian Bunk
>
> Moreover I get some weird networking problems which prevent setting up the
> routes (RNETLINK invalid argument messages) when I compile my kernel with
>
> So eventhough 4.0 is supposed to be supported, it doesn't work too well in
> my case.
I haven't heard of such a problem.
Please give a complete bug report:
- exact error messages
- kernel version
- self-compiled gcc or distrbution compiler?
> Mathieu Chouquet-Stringer
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
-
Jan-Benedict Glaw
> On Thu, Aug 04, 2005 at 08:54:47AM +0200, Jan-Benedict Glaw wrote:
> >...
> > Current GCC from CVS (plus minor configury patches) seems to work. We
> > had -fno-unit-at-a-time missing in our arch Makefile which hides a bug
> > in kernel's sources.
> >
> > I guess that if you remove -fno-unit-at-a-time from i386 and use a
> > current GCC, you'll run into that fun, too.
>
> What bug exactly?
-fno-unit-at-a-time grounded:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ grep fno-unit-at arch/i386/Makefile
# CFLAGS += $(call cc-option,-fno-unit-at-a-time)
For presenting it, I built a gcc right from CVS:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ i486-linux-gcc -v
Using built-in specs.
Target: i486-linux
Configured with: /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/src/gcc/configure --disable-multilib --with-newlib --disable-nls --enable-threads=no --disable-threads --enable-symvers=gnu --enable-__cxa_atexit --disable-shared --target=i486-linux --prefix=/home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr --enable-languages=c
Thread model: single
gcc version 4.1.0 20050802 (experimental)
...and here you can see it explode even on i386:
jbglaw@d2:~/test_gcc/linux-2.6.13-rc5-git3$ make CC=i486-linux-gcc V=1 bzImage
[...]
CHK include/asm-i386/asm_offsets.h
make -f scripts/Makefile.build obj=init
i486-linux-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /home/jbglaw/vax-linux/scm/build-20050802-192552-i486-linux/install/usr/lib/gcc/i486-linux/4.1.0/include -D__KERNEL__ -Iinclude -Wall -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -ffreestanding -O2 -fomit-frame-pointer -pipe -msoft-float -mpreferred-stack-boundary=2 -march=i686 -mtune=pentium4 -Iinclude/asm-i386/mach-default -Wdeclaration-after-statement -Wno-pointer-sign -DKBUILD_BASENAME=main -DKBUILD_MODNAME=main -c -o init/main.o init/main.c
init/main.c:415: error: tmp_cmdline causes a section type conflict
init/main.c:414: error: done causes a section type conflict
init/main.c:536: error: initcall_debug causes a section type conflict
include/asm/bugs.h:35: error: __setup_str_no_halt causes a section type conflict
include/asm/bugs.h:43: error: __setup_str_mca_pentium causes a section type conflict
include/asm/bugs.h:52: error: __setup_str_no_387 causes a section type conflict
init/main.c:146: error: __setup_str_nosmp causes a section type conflict
init/main.c:154: error: __setup_str_maxcpus causes a section type conflict
init/main.c:211: error: __setup_str_debug_kernel causes a section type conflict
init/main.c:212: error: __setup_str_quiet_kernel causes a section type conflict
init/main.c:220: error: __setup_str_loglevel causes a section type conflict
init/main.c:298: error: __setup_str_init_setup causes a section type conflict
init/main.c:543: error: __setup_str_initcall_debug_setup causes a section type conflict
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
MfG, JBG
Martin Drab
I guess kernel may not yet be ready to be compiled by the latest CVS GCC
4.1.x (currently HEAD). But it should (at least works for me) do the
latest CVS GCC 4.0.x.
Martin
Jan-Benedict Glaw
> > init/main.c:212: error: __setup_str_quiet_kernel causes a section type conflict
> > init/main.c:220: error: __setup_str_loglevel causes a section type conflict
> > init/main.c:298: error: __setup_str_init_setup causes a section type conflict
> > init/main.c:543: error: __setup_str_initcall_debug_setup causes a section type conflict
> > make[1]: *** [init/main.o] Error 1
> > make: *** [init] Error 2
>
> I guess kernel may not yet be ready to be compiled by the latest CVS GCC
> 4.1.x (currently HEAD). But it should (at least works for me) do the
> latest CVS GCC 4.0.x.
As I worte previously, I now again do regular compile runs with gcc-HEAD
for the VAX port and it works. ...but only, if -fno-unit-at-a-time is
supplied.
So I actually suspect two bugs: one in the kernel's sources (missing
"const" or rw/ro attributes) and -fno-unit-at-a-time disables some
gcc-internal tests that should have fired.
Denis Vlasenko
> From: Adrian Bunk <bu...@stusta.de>
> 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.
This is a rather strange form of "progress", especially
since in my experience newer gcc's do not show significant
reductions in code size...
--
vda
Bill Davidsen
> From: Adrian Bunk <bu...@stusta.de>
> 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.
I don't mean to offend anyone, but it seems that the gcc project, at
least WRT x86, has lost its way a bit. The compiler is getting slower,
and the generated code is not getting correspondingly faster. Or
smaller. I'm not sure about more correct...
Keeping 2.95 might not be a bad idea.
--
-bill davidsen (davi...@tmr.com)
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Joe
that 3.4 has quite matured and also has much smaller binary size from
3.3. 4.0 however is still too early in its development to come close
to surpassing 3.4.
With all the changes and deprications it seems pointless to have to
maintain extra code so 3 people can use an obsolete compiler.
Something more recent like 3.4 should be used as a bench.
Just my two cents.
David S. Miller
Date: Wed, 10 Aug 2005 20:02:33 -0400
> With all the changes and deprications it seems pointless to have to
> maintain extra code so 3 people can use an obsolete compiler.
This number is enormously greater than 3, and especially it's
important because the folks who are quite important to kernel
development (read as: Andrew Morton) rely on the build efficiency of
gcc-2.95 so that they can actually get their daily work done.
Some of us spend the majority of our time doing patch applying and
verification kernel builds, and often not much more than that.
Therefore kernel build time is enormously important, and gcc-2.95
is the best option as far as that goes.
Geert Uytterhoeven
> -sh-3.00# cat cpuinfo
> cpu : VAX
> cpu type : KA43
> cpu sid : 0x0b000006
> cpu sidex : 0x04010002
> page size : 4096
> BogoMIPS : 10.08
> -sh-3.00# cat version
> Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005
Any change we will see this code in mainline?
Or do you wait for a 25th anniversary of your hardware, or something like that?
;-)
Gr{oetje,eeting}s,
Geert (supporter of Linux
on old systems)
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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
Maciej W. Rozycki
> > -sh-3.00# cat cpuinfo
> > cpu : VAX
> > cpu type : KA43
> > cpu sid : 0x0b000006
> > cpu sidex : 0x04010002
> > page size : 4096
> > BogoMIPS : 10.08
> > -sh-3.00# cat version
> > Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005
>
> Any change we will see this code in mainline?
> Or do you wait for a 25th anniversary of your hardware, or something like that?
> ;-)
I guess the 25th anniversary has already happened -- there was even a
nice history of DEC computing published at that time as it coincided with
the 50th anniversary of the company itself. That's for VAX in general,
rather than a specific implementation, though.
Anyway I second the question, although I have a bit more interest in this
area these days and I may push the merge myslef if nobody else bothers.
;-)
Maciej
Jan-Benedict Glaw
> On Thu, 4 Aug 2005, Jan-Benedict Glaw wrote:
> > -sh-3.00# cat cpuinfo
> > cpu : VAX
> > cpu type : KA43
> > cpu sid : 0x0b000006
> > cpu sidex : 0x04010002
> > page size : 4096
> > BogoMIPS : 10.08
> > -sh-3.00# cat version
> > Linux version 2.6.12 (jbglaw@d2) (gcc version 4.1.0 20050803 (experimental)) #2 Wed Aug 3 23:42:11 CEST 2005
>
> Any change we will see this code in mainline?
That's the plan. We haven't publically talked about it yet, but we'd
probably like to present the code for review once we
- have enough hardware supported. At least local SCSI drivers
for the most common machines should be available, as well as
network drivers. That's not yet the case.
- have userspace working again. Currently, a very old gcc is
used. I'm working on uClibc (and thereafter GNU libc) in
conjunction with gcc-HEAD as time allows.
So yes, we want to show off the code, but we don't want to do that
publically and right now. There are still to many places where the code
needs some tidy-up (and be it whitespace and comment fixes), but
everybody is welcome to peek at our CVS repo
(http://sourceforge.net/cvs/?group_id=2626) or to join the mailing list
(at http://www.pergamentum.com/mailman/listinfo/linux-vax).
So if *you* are looking for some beginner's task to start with kernel
development, here you go! Oh, and SMP fun will hopefully start soon. A
machine is on the way and I hope it'll survive shipping :-)
VAX is also an interesting platform because it's another platform
offering TurboChannel slots. So if you're interested in those old Alphas
or DECstations, VAX is for you, too.
Bill Davidsen
>I'm for its removal. As for the gcc project "losing its way" consider
>that 3.4 has quite matured and also has much smaller binary size from
>3.3. 4.0 however is still too early in its development to come close
>to surpassing 3.4.
>
I consider that the compiler get bigger and slower with every release.
The tools used to find overlong paths in the kernel would work well for
gcc. Recent versions are painful, even with a decent SMP machine. The
people compiling on laptops could spend a day building with new versions.
--
bill davidsen <davi...@tmr.com>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
Jan-Benedict Glaw
> > I guess that if you remove -fno-unit-at-a-time from i386 and use a
> > current GCC, you'll run into that fun, too.
>
> What bug exactly?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23237