[2.6 patch] remove support for gcc < 3.2

[2.6 patch] remove support for gcc < 3.2

[Adrian Bunk]

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 <bunk@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
 ----

Re: [2.6 patch] remove support for gcc < 3.2

[David S. Miller]

From: Adrian Bunk <bunk@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.

Re: [2.6 patch] remove support for gcc < 3.2

[Nigel Cunningham]

Hi.

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.

Re: [2.6 patch] remove support for gcc < 3.2

[Denis Vlasenko]

On Monday 01 August 2005 01:36, David S. Miller wrote:
> From: Adrian Bunk <bunk@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

Re: [2.6 patch] remove support for gcc < 3.2

[Bill Davidsen]

David S. Miller wrote:
> From: Adrian Bunk <bunk@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 (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

Re: remove support for gcc < 3.2

[Joe]

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.

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.

Re: remove support for gcc < 3.2

[David S. Miller]

From: Joe <joecool1029@gmail.com>
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.

Re: remove support for gcc < 3.2

[Bill Davidsen]

Joe wrote:

>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 <davidsen@tmr.com>
  CTO TMR Associates, Inc
  Doing interesting things with small computers since 1979

Re: [2.6 patch] remove support for gcc < 3.2

[Kurt Wall]

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.

Re: [2.6 patch] remove support for gcc < 3.2

[Willy Tarreau]

On Sun, Jul 31, 2005 at 11:01:45PM -0400, Kurt Wall wrote:
> 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

Re: [2.6 patch] remove support for gcc < 3.2

[Miles Bader]

Adrian Bunk <bunk@stusta.de> writes:
> 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]

Re: [2.6 patch] remove support for gcc < 3.2

[Jan-Benedict Glaw]

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

On Mon, 2005-08-01 00:26:07 +0200, Adrian Bunk <bunk@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
[...]
> [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       jbglaw@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));

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

Re: [2.6 patch] remove support for gcc < 3.2

[Gustavo Guillermo Pérez]

El Domingo, 31 de Julio de 2005 17:26, escribió:
> This patch removes support for gcc < 3.2 .
> [1] support removed: 2.95, 2.96, 3.0, 3.1
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 fine 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 older 
hardware, then we are forced to build gcc 3.4 or something like.

:(

-- 
Gustavo Guillermo Pérez
Compunauta uLinux
www.compunauta.com

Re: [2.6 patch] remove support for gcc < 3.2

[Mathieu Chouquet-Stringer]

gustavo@compunauta.com (Gustavo Guillermo Pérez) writes:
> 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 fine 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 older 
> 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 with
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

networking problems when using gcc 4.0.1

[Adrian Bunk]

On Wed, Aug 03, 2005 at 08:53:52PM -0400, Mathieu Chouquet-Stringer wrote:
> 
> Moreover I get some weird networking problems which prevent setting up the
> routes (RNETLINK invalid argument messages) when I compile my kernel with
> 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.

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

Re: [2.6 patch] remove support for gcc < 3.2

[Dave Airlie]

On 8/1/05, Adrian Bunk <bunk@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...

Dave.

Re: [2.6 patch] remove support for gcc < 3.2

[Jan-Benedict Glaw]

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

On Thu, 2005-08-04 11:34:27 +1000, Dave Airlie <airlied@gmail.com> wrote:
> On 8/1/05, Adrian Bunk <bunk@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.

-- 
Jan-Benedict Glaw       jbglaw@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));

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

Re: [2.6 patch] remove support for gcc < 3.2

[Adrian Bunk]

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?

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

Re: [2.6 patch] remove support for gcc < 3.2

[Jan-Benedict Glaw]

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

On Thu, 2005-08-04 22:38:31 +0200, Adrian Bunk <bunk@stusta.de> wrote:
> 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

-- 
Jan-Benedict Glaw       jbglaw@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));

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

Re: [2.6 patch] remove support for gcc < 3.2

[Martin Drab]

On Fri, 5 Aug 2005, Jan-Benedict Glaw wrote:

> On Thu, 2005-08-04 22:38:31 +0200, Adrian Bunk <bunk@stusta.de> wrote:
> > 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

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

Re: [2.6 patch] remove support for gcc < 3.2

[Jan-Benedict Glaw]

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

On Fri, 2005-08-05 23:30:04 +0200, Martin Drab <drab@kepler.fjfi.cvut.cz> wrote:
> > 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.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@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));

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

Re: [2.6 patch] remove support for gcc < 3.2

[Jan-Benedict Glaw]

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

On Thu, 2005-08-04 22:38:31 +0200, Adrian Bunk <bunk@stusta.de> wrote:
> On Thu, Aug 04, 2005 at 08:54:47AM +0200, Jan-Benedict Glaw wrote:
> > 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

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@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));

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

Re: [2.6 patch] remove support for gcc < 3.2

[Geert Uytterhoeven]

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?
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 -- 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: [2.6 patch] remove support for gcc < 3.2

[Maciej W. Rozycki]

On Fri, 12 Aug 2005, Geert Uytterhoeven 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?
> 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

Re: [2.6 patch] remove support for gcc < 3.2

[Jan-Benedict Glaw]

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

On Fri, 2005-08-12 09:40:18 +0200, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> 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.

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@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));

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