RFC: drop support for gcc < 4.0

RFC: drop support for gcc < 4.0

[Adrian Bunk]

On Tue, Aug 21, 2007 at 09:31:03AM -0700, Randy Dunlap wrote:
> On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
> 
> > Here are some more of, probably well-known, warnings with attached
> > testing-only .config.
> >...
> > drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> >...
> 
> What gcc version?  I don't get the arch_ warnings in drivers/pci/msi.c.

Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.

You can reproduce it with a more recent gcc when adding 
-fno-unit-at-a-time to the CFLAGS.

And it's becoming a real maintainance problem that not only this problem 
but also other problems like some section mismatches [2] are only 
present without unit-at-a-time.

Currently we support 6 different stable gcc release series, and it might 
be the right time to consider dropping support for the older ones.

Are there any architectures still requiring a gcc < 4.0 ?

> ~Randy

cu
Adrian

[1] unit-at-a-time was added in gcc 3.4, but on gcc 3.4 we disable it on
    i386 due to stack usage problems
[2] example: static __init function with exactly one caller, and this
             caller is non-__init

-- 

       "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: RFC: drop support for gcc < 4.0

[Russell King]

On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> On Tue, Aug 21, 2007 at 09:31:03AM -0700, Randy Dunlap wrote:
> > On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
> > 
> > > Here are some more of, probably well-known, warnings with attached
> > > testing-only .config.
> > >...
> > > drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > > drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > > drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> > >...
> > 
> > What gcc version?  I don't get the arch_ warnings in drivers/pci/msi.c.
> 
> Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
> 
> You can reproduce it with a more recent gcc when adding 
> -fno-unit-at-a-time to the CFLAGS.
> 
> And it's becoming a real maintainance problem that not only this problem 
> but also other problems like some section mismatches [2] are only 
> present without unit-at-a-time.
> 
> Currently we support 6 different stable gcc release series, and it might 
> be the right time to consider dropping support for the older ones.
> 
> Are there any architectures still requiring a gcc < 4.0 ?

I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
From my point of view, gcc 4 compilers have been something of a development
thing as far as the ARM architecture goes.  Also, gcc 3.4.3 is faster and
significantly less noisy than gcc 4.

-- 
Russell King
 Linux kernel    2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:

Re: RFC: drop support for gcc < 4.0

[Kyle McMartin]

On Tue, Aug 21, 2007 at 06:54:53PM +0100, Russell King wrote:
> I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
> From my point of view, gcc 4 compilers have been something of a development
> thing as far as the ARM architecture goes.  Also, gcc 3.4.3 is faster and
> significantly less noisy than gcc 4.
> 

+1, similar reasons, for parisc. Not that gcc4 doesn't work, but there's
some cases where gcc 3.4 still generates better code...

Regards,
	Kyle M.

Re: RFC: drop support for gcc < 4.0

[Chris Wedgwood]

On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:

> Are there any architectures still requiring a gcc < 4.0 ?

Yes, sadly in some places (embedded) there are people with older
compiler who want newer kernels.

Re: RFC: drop support for gcc < 4.0

[Adrian Bunk]

On Tue, Aug 21, 2007 at 06:54:53PM +0100, Russell King wrote:
> On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> > On Tue, Aug 21, 2007 at 09:31:03AM -0700, Randy Dunlap wrote:
> > > On Tue, 21 Aug 2007 15:20:38 +0200 Jarek Poplawski wrote:
> > > 
> > > > Here are some more of, probably well-known, warnings with attached
> > > > testing-only .config.
> > > >...
> > > > drivers/pci/msi.c:686: warning: weak declaration of `arch_msi_check_device' after first use results in unspecified behavior
> > > > drivers/pci/msi.c:698: warning: weak declaration of `arch_setup_msi_irqs' after first use results in unspecified behavior
> > > > drivers/pci/msi.c:718: warning: weak declaration of `arch_teardown_msi_irqs' after first use results in unspecified behavior
> > > >...
> > > 
> > > What gcc version?  I don't get the arch_ warnings in drivers/pci/msi.c.
> > 
> > Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
> > 
> > You can reproduce it with a more recent gcc when adding 
> > -fno-unit-at-a-time to the CFLAGS.
> > 
> > And it's becoming a real maintainance problem that not only this problem 
> > but also other problems like some section mismatches [2] are only 
> > present without unit-at-a-time.
> > 
> > Currently we support 6 different stable gcc release series, and it might 
> > be the right time to consider dropping support for the older ones.
> > 
> > Are there any architectures still requiring a gcc < 4.0 ?
> 
> I want to keep support for gcc 3.4.3 for ARM for the forseeable future.
> >From my point of view, gcc 4 compilers have been something of a development
> thing as far as the ARM architecture goes.
>...

It is an option to say "gcc >= 4.0 on i386 and >= 3.4 on all other 
architectures is required".

> Russell King

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: RFC: drop support for gcc < 4.0

[Andi Kleen]

On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.

Actually there are widely used 3.3 variants that support unit-at-a-time
(e.g. 3.3-hammer which was shipped by several distributions for some time)

There are still a lot of systems around which use gcc 3.3 (less so with
3.4). Unless there's a major bug that is hard to work around I would
prefer to keep it supported.

Bogus warnings should be relatively harmless.

> And it's becoming a real maintainance problem that not only this problem 
> but also other problems like some section mismatches [2] are only 
> present without unit-at-a-time.

The unit-at-a-time output order is not defined, so even if it works
with the current compiler a compiler change might still trigger
that problem. So it would be better to fix those anyways.

-Andi

[RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Dave Hansen]

For the /proc/<pid>/pagemap code[1], we need to able to query how
much virtual address space a particular task has.  The trick is
that we do it through /proc and can't use TASK_SIZE since it
references "current" on some arches.  The process opening the
/proc file might be a 32-bit process opening a 64-bit process's
pagemap file.

x86_64 already has a TASK_SIZE_OF() macro:

#define TASK_SIZE_OF(child)     ((test_tsk_thread_flag(child, TIF_IA32)) ? IA32_PAGE_OFFSET : TASK_SIZE64)

I'd like to have that for other architectures.  So, add it
for all the architectures that actually use "current" in 
their TASK_SIZE.  For the others, just add a quick #define
in sched.h to use plain old TASK_SIZE.

1. http://www.linuxworld.com/news/2007/042407-kernel.html

Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---

 lxc-dave/include/asm-ia64/processor.h    |    3 ++-
 lxc-dave/include/asm-parisc/processor.h  |    3 ++-
 lxc-dave/include/asm-powerpc/processor.h |    4 +++-
 lxc-dave/include/asm-s390/processor.h    |    2 ++
 lxc-dave/include/linux/sched.h           |    4 ++++
 5 files changed, 13 insertions(+), 3 deletions(-)

diff -puN include/asm-ia64/processor.h~task_size_of include/asm-ia64/processor.h
--- lxc/include/asm-ia64/processor.h~task_size_of	2007-08-07 15:30:54.000000000 -0700
+++ lxc-dave/include/asm-ia64/processor.h	2007-08-07 15:30:54.000000000 -0700
@@ -31,7 +31,8 @@
  * each (assuming 8KB page size), for a total of 8TB of user virtual
  * address space.
  */
-#define TASK_SIZE		(current->thread.task_size)
+#define TASK_SIZE_OF(tsk)	((tsk)->thread.task_size)
+#define TASK_SIZE       	TASK_SIZE_OF(current)
 
 /*
  * This decides where the kernel will search for a free chunk of vm
diff -puN include/asm-parisc/processor.h~task_size_of include/asm-parisc/processor.h
--- lxc/include/asm-parisc/processor.h~task_size_of	2007-08-07 15:30:54.000000000 -0700
+++ lxc-dave/include/asm-parisc/processor.h	2007-08-07 15:30:54.000000000 -0700
@@ -32,7 +32,8 @@
 #endif
 #define current_text_addr() ({ void *pc; current_ia(pc); pc; })
 
-#define TASK_SIZE               (current->thread.task_size)
+#define TASK_SIZE_OF(tsk)       ((tsk)->thread.task_size)
+#define TASK_SIZE	         (current->thread.task_size)
 #define TASK_UNMAPPED_BASE      (current->thread.map_base)
 
 #define DEFAULT_TASK_SIZE32	(0xFFF00000UL)
diff -puN include/asm-powerpc/processor.h~task_size_of include/asm-powerpc/processor.h
--- lxc/include/asm-powerpc/processor.h~task_size_of	2007-08-07 15:30:54.000000000 -0700
+++ lxc-dave/include/asm-powerpc/processor.h	2007-08-07 15:30:54.000000000 -0700
@@ -107,7 +107,9 @@ extern struct task_struct *last_task_use
  */
 #define TASK_SIZE_USER32 (0x0000000100000000UL - (1*PAGE_SIZE))
 
-#define TASK_SIZE (test_thread_flag(TIF_32BIT) ? \
+#define TASK_SIZE	  (test_thread_flag(TIF_32BIT) ? \
+		TASK_SIZE_USER32 : TASK_SIZE_USER64)
+#define TASK_SIZE_OF(tsk) (test_tsk_thread_flag(tsk, TIF_32BIT) ? \
 		TASK_SIZE_USER32 : TASK_SIZE_USER64)
 
 /* This decides where the kernel will search for a free chunk of vm
diff -puN include/asm-s390/processor.h~task_size_of include/asm-s390/processor.h
--- lxc/include/asm-s390/processor.h~task_size_of	2007-08-07 15:30:54.000000000 -0700
+++ lxc-dave/include/asm-s390/processor.h	2007-08-07 15:30:54.000000000 -0700
@@ -75,6 +75,8 @@ extern struct task_struct *last_task_use
 
 # define TASK_SIZE		(test_thread_flag(TIF_31BIT) ? \
 					(0x80000000UL) : (0x40000000000UL))
+# define TASK_SIZE_OF(tsk)	(test_tsk_thread_flag(tsk, TIF_31BIT) ? \
+					(0x80000000UL) : (0x40000000000UL))
 # define TASK_UNMAPPED_BASE	(TASK_SIZE / 2)
 # define DEFAULT_TASK_SIZE	(0x40000000000UL)
 
diff -puN include/linux/sched.h~task_size_of include/linux/sched.h
--- lxc/include/linux/sched.h~task_size_of	2007-08-07 15:30:54.000000000 -0700
+++ lxc-dave/include/linux/sched.h	2007-08-07 15:30:54.000000000 -0700
@@ -1712,6 +1712,10 @@ static inline void inc_syscw(struct task
 }
 #endif
 
+#ifndef TASK_SIZE_OF
+#define TASK_SIZE_OF(tsk)	TASK_SIZE
+#endif
+
 #endif /* __KERNEL__ */
 
 #endif
_

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Matthew Wilcox]

On Tue, Aug 21, 2007 at 12:38:35PM -0700, Dave Hansen wrote:
> I'd like to have that for other architectures.  So, add it
> for all the architectures that actually use "current" in 
> their TASK_SIZE.  For the others, just add a quick #define
> in sched.h to use plain old TASK_SIZE.

MIPS seems to do things a little differently ... Ralf, what should Dave
be doing here?

#define TASK_SIZE32     0x7fff8000UL
#define TASK_SIZE       0x10000000000UL

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: RFC: drop support for gcc < 4.0

[Adrian Bunk]

On Tue, Aug 21, 2007 at 09:19:59PM +0200, Andi Kleen wrote:
> On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> > Obviously a gcc <= 3.4 [1], and therefore no unit-at-a-time.
> 
> Actually there are widely used 3.3 variants that support unit-at-a-time
> (e.g. 3.3-hammer which was shipped by several distributions for some time)
> 
> There are still a lot of systems around which use gcc 3.3 (less so with
> 3.4). Unless there's a major bug that is hard to work around I would
> prefer to keep it supported.
> 
> Bogus warnings should be relatively harmless.

How many kernel developers use such old gcc versions?

And how many people notice the valid modpost warnings that can indicate
a runtime Oops?

> > And it's becoming a real maintainance problem that not only this problem 
> > but also other problems like some section mismatches [2] are only 
> > present without unit-at-a-time.
> 
> The unit-at-a-time output order is not defined, so even if it works
> with the current compiler a compiler change might still trigger
> that problem. So it would be better to fix those anyways.

The example [2] from my email is guaranteed to not be a problem with 
unit-at-a-time (as long as unit-at-a-time implies 
inline-functions-called-once - and that's although theoretically 
possible quite unlikely to change in practice).

This example is for a bug that should be fixed, but my point is the
maintainability, IOW: issues with older compilers might not be 
discovered and fixed before they go into a stable kernel.

We currently support 6 different stable gcc release series plus heavily 
modified vendor branches like 3.3-hammer. We can discuss whether it is 
now already the right time, and where to make the cut, but medium-term 
we must reduce the number of supported compilers.

> -Andi

cu
Adrian

[2] example: static __init function with exactly one caller, and this
             caller is non-__init

-- 

       "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: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Matthew Wilcox]

On Tue, Aug 21, 2007 at 09:54:33PM +0200, Adrian Bunk wrote:
> We currently support 6 different stable gcc release series plus heavily 
> modified vendor branches like 3.3-hammer. We can discuss whether it is 
> now already the right time, and where to make the cut, but medium-term 
> we must reduce the number of supported compilers.

I don't think that's feasible.  We're dealing with a situation where:

 - GCC aim to release a new compiler series every 6 months.
   Fortunately, they don't achieve this goal, but they do release every
   12 months or thereabouts [1].
 - Enterprise distros are supported for seven years
 - We still care about people being able to compile kernels on
   enterprise distros that are still supported by their vendor.

Yes, it causes us some pain to support all these different compilers,
but it's not *that* big a pain.

[1] Release dates, according to the GCC website

2007-05-17 4.2.0	(14 months)
2006-02-28 4.1.0	(10 months)
2005-04-20 4.0.0	(12 months)
2004-04-20 3.4.0	(11 months)
2003-05-20 3.3		(12 months, ignoring gcc 3.2 which was really 3.1.2)
2002-05-15 3.1		(11 months)
2001-06-18 3.0

-- 
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Re: RFC: drop support for gcc < 4.0

[Linus Torvalds]

On Tue, 21 Aug 2007, Adrian Bunk wrote:
> > 
> > Bogus warnings should be relatively harmless.
> 
> How many kernel developers use such old gcc versions?

It's NOT about "kernel developers".

It's about random people testing kernels.

If we make it harder for people to test kernels, we're going to lose. So 
no, I vote for *not* cutting off old gcc versions unless it's absolutely 
fatal.

		Linus

Re: RFC: drop support for gcc < 4.0

[Adrian Bunk]

On Tue, Aug 21, 2007 at 01:08:25PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 21 Aug 2007, Adrian Bunk wrote:
> > > 
> > > Bogus warnings should be relatively harmless.
> > 
> > How many kernel developers use such old gcc versions?
> 
> It's NOT about "kernel developers".
> 
> It's about random people testing kernels.
> 
> If we make it harder for people to test kernels, we're going to lose. So 
> no, I vote for *not* cutting off old gcc versions unless it's absolutely 
> fatal.

How many people e.g. test -rc kernels compiled with gcc 3.2?

> 		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: RFC: drop support for gcc < 4.0

[Linus Torvalds]

On Tue, 21 Aug 2007, Adrian Bunk wrote:
> 
> How many people e.g. test -rc kernels compiled with gcc 3.2?

How could anybody know?

		Linus

Re: RFC: drop support for gcc < 4.0

[Glauber de Oliveira Costa]

On 8/21/07, Chris Wedgwood <cw@f00f.org> wrote:
> On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
>
> > Are there any architectures still requiring a gcc < 4.0 ?
>
> Yes, sadly in some places (embedded) there are people with older
> compiler who want newer kernels.

Last time I tried a mips build, it would fail the compile unless I was
using _exactly_ 3.4.4 (I didn't tried older versions, but did try
3.4.6, for ex.). So I also think the 3.4 series will still have to be
around for a while.

-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: RFC: drop support for gcc < 4.0

[Segher Boessenkool]

> How many people e.g. test -rc kernels compiled with gcc 3.2?

Why would that matter?  It either works or not.  If it doesn't
work, it can either be fixed, or support for that old compiler
version can be removed.

The only other policy than "only remove support if things are
badly broken" would be "only support what the GCC team supports",
which would be >= 4.1 now; and there are very good arguments for
supporting more than that with the Linux kernel.


Segher

Re: RFC: drop support for gcc < 4.0

[Segher Boessenkool]

> Last time I tried a mips build, it would fail the compile unless I was
> using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> 3.4.6, for ex.).

If 3.4.4 works where 3.4.6 doesn't, you should report this as a
bug; either here, or to the GCC team (but please be aware that the
3.4 series isn't supported anymore), or to whoever built that
compiler for you.

> So I also think the 3.4 series will still have to be
> around for a while.

Huh?  3.4 doesn't work for you, so that's why it should stay
a supported compiler?


Segher

Re: RFC: drop support for gcc < 4.0

[Glauber de Oliveira Costa]

On 8/21/07, Segher Boessenkool <segher@kernel.crashing.org> wrote:
> > Last time I tried a mips build, it would fail the compile unless I was
> > using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> > 3.4.6, for ex.).
>
> If 3.4.4 works where 3.4.6 doesn't, you should report this as a
> bug; either here, or to the GCC team (but please be aware that the
> 3.4 series isn't supported anymore), or to whoever built that
> compiler for you.

I didn't bothered reporting it here because linux-mips website quotes
explicitly  the dependency on 3.4.4. So at least, I imagined they are
aware of it. (And as you said, no point in reporting it to gcc...)

> > So I also think the 3.4 series will still have to be
> > around for a while.
>
> Huh?  3.4 doesn't work for you, so that's why it should stay
> a supported compiler?

3.4.4 does. anyway, by this phrase, I only meant: "Dropping support
for 3.4 series won't help in this case"

-- 
Glauber de Oliveira Costa.
"Free as in Freedom"
http://glommer.net

"The less confident you are, the more serious you have to act."

Re: RFC: drop support for gcc < 4.0

[Adrian Bunk]

On Tue, Aug 21, 2007 at 10:49:49PM +0200, Segher Boessenkool wrote:
>> How many people e.g. test -rc kernels compiled with gcc 3.2?
>
> Why would that matter?  It either works or not.  If it doesn't
> work, it can either be fixed, or support for that old compiler
> version can be removed.

One bug report "kernel doesn't work / crash / ... when compiled with
gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost 
in the big pile of unhandled bugs, not cause the removal of gcc 3.2 
support...

> The only other policy than "only remove support if things are
> badly broken" would be "only support what the GCC team supports",
> which would be >= 4.1 now; and there are very good arguments for
> supporting more than that with the Linux kernel.

No, it's not about bugs in gcc, it's about kernel+gcc combinations that 
are mostly untested but officially supported.

E.g. how many kernel developers use kernels compiled without 
unit-at-a-time? And unit-at-a-time does paper over some bugs,
e.g. at about half a dozen section mismatch bugs I've fixed
recently are not present with it.

But as the discussions have shown gcc 4.0 is currently too high for 
making a cut, and it is not yet the right time for raising the minimum 
required gcc version.

> Segher

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

RFC: drop support for gcc < 4.0

[Oliver Pinter]

Hi all!

I think it's bad idea, when removing support for gcc3.x, while some
people using debian 3.1 at now and under debian 3.1 the default
comiler is 3.3.5, when I good know or not!?

Re: RFC: drop support for gcc < 4.0

[James Bottomley]

On Tue, 2007-08-21 at 23:21 +0200, Adrian Bunk wrote:
> On Tue, Aug 21, 2007 at 10:49:49PM +0200, Segher Boessenkool wrote:
> >> How many people e.g. test -rc kernels compiled with gcc 3.2?
> >
> > Why would that matter?  It either works or not.  If it doesn't
> > work, it can either be fixed, or support for that old compiler
> > version can be removed.
> 
> One bug report "kernel doesn't work / crash / ... when compiled with
> gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost 
> in the big pile of unhandled bugs, not cause the removal of gcc 3.2 
> support...

What's the bugzilla or pointer to this report please?  Those of us who
use gcc-3 as the default kernel compiler will take it seriously (if it
looks to have an impact to our kernel builds) otherwise we can tell you
it's unreproducible/not a problem etc.

James


> > The only other policy than "only remove support if things are
> > badly broken" would be "only support what the GCC team supports",
> > which would be >= 4.1 now; and there are very good arguments for
> > supporting more than that with the Linux kernel.
> 
> No, it's not about bugs in gcc, it's about kernel+gcc combinations that 
> are mostly untested but officially supported.
> 
> E.g. how many kernel developers use kernels compiled without 
> unit-at-a-time? And unit-at-a-time does paper over some bugs,
> e.g. at about half a dozen section mismatch bugs I've fixed
> recently are not present with it.
> 
> But as the discussions have shown gcc 4.0 is currently too high for 
> making a cut, and it is not yet the right time for raising the minimum 
> required gcc version.
> 
> > Segher
> 
> cu
> Adrian
> 

Re: RFC: drop support for gcc < 4.0

[Adrian Bunk]

On Tue, Aug 21, 2007 at 04:49:38PM -0500, James Bottomley wrote:
> On Tue, 2007-08-21 at 23:21 +0200, Adrian Bunk wrote:
> > On Tue, Aug 21, 2007 at 10:49:49PM +0200, Segher Boessenkool wrote:
> > >> How many people e.g. test -rc kernels compiled with gcc 3.2?
> > >
> > > Why would that matter?  It either works or not.  If it doesn't
> > > work, it can either be fixed, or support for that old compiler
> > > version can be removed.
> > 
> > One bug report "kernel doesn't work / crash / ... when compiled with
> > gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost 
> > in the big pile of unhandled bugs, not cause the removal of gcc 3.2 
> > support...
> 
> What's the bugzilla or pointer to this report please?  Those of us who
> use gcc-3 as the default kernel compiler will take it seriously (if it
> looks to have an impact to our kernel builds) otherwise we can tell you
> it's unreproducible/not a problem etc.

This was an example in response to Segher's point we would remove 
support for a gcc version in such a case.

I remember we had such issues, but I don't find any pointer to a 
specific one at the moment.

I'll keep you informed when bug reports come in that only occur with 
older gcc versions and that aren't easily fixable.

> James

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: RFC: drop support for gcc < 4.0

[Segher Boessenkool]

>>> How many people e.g. test -rc kernels compiled with gcc 3.2?
>>
>> Why would that matter?  It either works or not.  If it doesn't
>> work, it can either be fixed, or support for that old compiler
>> version can be removed.
>
> One bug report "kernel doesn't work / crash / ... when compiled with
> gcc 3.2, but works when compiled with gcc 4.2" will most likely be lost
> in the big pile of unhandled bugs, not cause the removal of gcc 3.2
> support...

While that might be true, it's a separate problem.

>> The only other policy than "only remove support if things are
>> badly broken" would be "only support what the GCC team supports",
>> which would be >= 4.1 now; and there are very good arguments for
>> supporting more than that with the Linux kernel.
>
> No, it's not about bugs in gcc, it's about kernel+gcc combinations that
> are mostly untested but officially supported.

What does "officially supported" mean?  Especially the
"officially" part.  Is this documented somewhere?

> E.g. how many kernel developers use kernels compiled without
> unit-at-a-time? And unit-at-a-time does paper over some bugs,
> e.g. at about half a dozen section mismatch bugs I've fixed
> recently are not present with it.

If any developer is interested in supporting some certain old
compiler version, he should be testing regularly with it.  Sounds
like that's you ;-)

If no developer is interested, we shouldn't claim to support
using that compiler version.

> But as the discussions have shown gcc 4.0 is currently too high for
> making a cut, and it is not yet the right time for raising the minimum
> required gcc version.

Agreed.


Segher

Re: RFC: drop support for gcc < 4.0

[Robert P. J. Day]

On Tue, 21 Aug 2007, Adrian Bunk wrote:

> It is an option to say "gcc >= 4.0 on i386 and >= 3.4 on all other
> architectures is required".

  if you're going to do something like that, you might as well take
the extra step and start keeping track of which versions of gcc work
with which architectures, along the lines of what dan kegel did with
the results matrix of crosstool:

http://www.kegel.com/crosstool/crosstool-0.43/buildlogs/

  i'm being only moderately facetious, of course but, on the other
hand, if there's all this anecdotal information regarding which
combinations work and which don't, maybe it's worth codifying that
into a compilation check somewhere in the build process.

  after all, at the moment in init/main.c, any gcc < 3.2 is rejected
outright, while gcc-4.1.0 generates a warning.  that's incredibly ad
hoc and certainly incomplete.  might as well just write a script for
the scripts/ directory which accepts an architecture and a version of
gcc and tells you what the current situation is and what you can do
about it.

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca
========================================================================

Re: RFC: drop support for gcc < 4.0

[Jarek Poplawski]

On Wed, Aug 22, 2007 at 02:08:33AM +0200, Segher Boessenkool wrote:
> >>>How many people e.g. test -rc kernels compiled with gcc 3.2?

I confirm gcc version:

~/src/linux-2.6.23-rc3$ gcc -v
Reading specs from /usr/lib/gcc-lib/i486-slackware-linux/3.2.3/specs
Configured with: ../gcc-3.2.3/configure --prefix=/usr --enable-shared
 --enable-threads=posix --enable-__cxa_atexit --disable-checkingi
 --with-gnu-ld --verbose --target=i486-slackware-linux
 --host=i486-slackware-linux
Thread model: posix
gcc version 3.2.3

glibc-2.3.2

Sorry, you have to guess this, but, after reporting long time ago some
acpi make warnings, I didn't even suspect anybody would be interested
more this time...

It's an old box with Slackware 9.1, and this make is the last stage
of testing such a hot kernel version... But, according to README gcc
3.2 seems to be legal. (I hope there would be some warning about gcc
too old, anyway.)

Cheers,
Jarek P.

Re: RFC: drop support for gcc < 4.0

[Thomas Bogendoerfer]

On Tue, Aug 21, 2007 at 05:41:04PM -0300, Glauber de Oliveira Costa wrote:
> On 8/21/07, Chris Wedgwood <cw@f00f.org> wrote:
> > On Tue, Aug 21, 2007 at 07:35:50PM +0200, Adrian Bunk wrote:
> >
> > > Are there any architectures still requiring a gcc < 4.0 ?
> >
> > Yes, sadly in some places (embedded) there are people with older
> > compiler who want newer kernels.
> 
> Last time I tried a mips build, it would fail the compile unless I was
> using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> 3.4.6, for ex.). So I also think the 3.4 series will still have to be
> around for a while.

that's fixed and I'm happiliy building the MIPS tree with gcc 3.3.3.
And I would be very unhappy to upgrade all my crosscompiler just because
someone thinks nobody build -rc kernel with older compilers. I do.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea.                                                [ RFC1925, 2.3 ]

Re: RFC: drop support for gcc < 4.0

[Jarek Poplawski]

On Tue, Aug 21, 2007 at 01:32:50PM -0700, Linus Torvalds wrote:
> 
> 
> On Tue, 21 Aug 2007, Adrian Bunk wrote:
> > 
> > How many people e.g. test -rc kernels compiled with gcc 3.2?
> 
> How could anybody know?

It shouldn't be so hard:

a) statistically: by doing some random math with:

int number_of_seemingly_gcc3.2_reports_eg_per_rc;
int number_of_all_such_reports_eg_per_rc;
int estimated_number_of_all_users_or_developers;
(or maybe some more...)

b) precisely (or even more): by adding proper and often updated
announcements, e.g:

"drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
(BTW, Angelina and Brad will be very suprised this warning is
yet possible!!!)"

Regards,
Jarek P.

Re: RFC: drop support for gcc < 4.0

[Jan Engelhardt]

On Aug 21 2007 23:41, Oliver Pinter wrote:
>I think it's bad idea, when removing support for gcc3.x, while some
>people using debian 3.1 at now and under debian 3.1 the default
>comiler is 3.3.5, when I good know or not!?

They always lag behind.


	Jan
-- 

Re: RFC: drop support for gcc < 4.0

[Jarek Poplawski]

On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
> 
> On Aug 21 2007 23:41, Oliver Pinter wrote:
> >I think it's bad idea, when removing support for gcc3.x, while some
> >people using debian 3.1 at now and under debian 3.1 the default
> >comiler is 3.3.5, when I good know or not!?
> 
> They always lag behind.

Yes! Probably that's why they are so darn good!

Jarek P.

Re: RFC: drop support for gcc < 4.0

[Jan Engelhardt]

On Aug 22 2007 10:08, Jarek Poplawski wrote:
>On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
>> 
>> On Aug 21 2007 23:41, Oliver Pinter wrote:
>> >I think it's bad idea, when removing support for gcc3.x, while some
>> >people using debian 3.1 at now and under debian 3.1 the default
>> >comiler is 3.3.5, when I good know or not!?
>> 
>> They always lag behind.
>
>Yes! Probably that's why they are so darn good!

ISTR that even Ubuntu overtook Debian... what about Debian 4.x?


	Jan
-- 

Re: RFC: drop support for gcc < 4.0

[Michal Piotrowski]

Hi,

On 22/08/07, Jan Engelhardt <jengelh@computergmbh.de> wrote:
>
> On Aug 22 2007 10:08, Jarek Poplawski wrote:
> >On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
> >>
> >> On Aug 21 2007 23:41, Oliver Pinter wrote:
> >> >I think it's bad idea, when removing support for gcc3.x, while some
> >> >people using debian 3.1 at now and under debian 3.1 the default
> >> >comiler is 3.3.5, when I good know or not!?
> >>
> >> They always lag behind.
> >
> >Yes! Probably that's why they are so darn good!
>
> ISTR that even Ubuntu overtook Debian... what about Debian 4.x?

They are using gcc 4.1.1 as default
http://packages.debian.org/stable/devel/gcc

Anyway, IMO dropping support for a compiler just because of warnings
it is a bad thing.

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/

Re: RFC: drop support for gcc < 4.0

[Martin Michlmayr]

* Jan Engelhardt <jengelh@computergmbh.de> [2007-08-22 09:57]:
> >I think it's bad idea, when removing support for gcc3.x, while some
> >people using debian 3.1 at now and under debian 3.1 the default
> >comiler is 3.3.5, when I good know or not!?
> They always lag behind.

Debian 4.0 has GCC 4.1 as the default compiler, and we use 4.1 to
compile our kernels on all architectures except of m68k.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: RFC: drop support for gcc < 4.0

[Jarek Poplawski]

On Wed, Aug 22, 2007 at 10:10:16AM +0200, Jan Engelhardt wrote:
> 
> On Aug 22 2007 10:08, Jarek Poplawski wrote:
> >On Wed, Aug 22, 2007 at 09:57:04AM +0200, Jan Engelhardt wrote:
> >> 
> >> On Aug 21 2007 23:41, Oliver Pinter wrote:
> >> >I think it's bad idea, when removing support for gcc3.x, while some
> >> >people using debian 3.1 at now and under debian 3.1 the default
> >> >comiler is 3.3.5, when I good know or not!?
> >> 
> >> They always lag behind.
> >
> >Yes! Probably that's why they are so darn good!
> 
> ISTR that even Ubuntu overtook Debian... what about Debian 4.x?

I'm glad with KNOPPIX 4.0 too. But, I hope we don't think about Debian
3.1 etc. for a new box & new installation!

Since I've found lynx or links plus some html tool is not enough (too
dangerous) to configure locally cups or samba (don't remember now,
it was around the beginning of Ubuntu), and there is X and probably
gnome necessary for this, and it wasn't like this with other distros,
I think Ubuntu's way of thinking is definitely too good for me...

Jarek P.

PS: this could look like some flame war, or something, so let's say
all (GPL2) Linux distros and all gcc versions are extremely nice!
(...at least not less nice than BSDs...)

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[David Howells]

Dave Hansen <haveblue@us.ibm.com> wrote:

> For the /proc/<pid>/pagemap code[1], we need to able to query how
> much virtual address space a particular task has.

How does this relate to NOMMU conditions?

David

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Ralf Baechle]

On Tue, Aug 21, 2007 at 01:43:09PM -0600, Matthew Wilcox wrote:

> On Tue, Aug 21, 2007 at 12:38:35PM -0700, Dave Hansen wrote:
> > I'd like to have that for other architectures.  So, add it
> > for all the architectures that actually use "current" in 
> > their TASK_SIZE.  For the others, just add a quick #define
> > in sched.h to use plain old TASK_SIZE.
> 
> MIPS seems to do things a little differently ... Ralf, what should Dave
> be doing here?
> 
> #define TASK_SIZE32     0x7fff8000UL
> #define TASK_SIZE       0x10000000000UL

Indeed. Below patch should do the trick.

  Ralf

Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

diff --git a/include/asm-mips/processor.h b/include/asm-mips/processor.h
index 83bc945..0e79e03 100644
--- a/include/asm-mips/processor.h
+++ b/include/asm-mips/processor.h
@@ -45,6 +45,8 @@ extern unsigned int vced_count, vcei_count;
  * space during mmap's.
  */
 #define TASK_UNMAPPED_BASE	(PAGE_ALIGN(TASK_SIZE / 3))
+#define TASK_SIZE_OF(tsk)						\
+	(test_thread_flag(TIF_32BIT_ADDR) ? TASK_SIZE32 : TASK_SIZE)
 #endif
 
 #ifdef CONFIG_64BIT
@@ -65,6 +67,8 @@ extern unsigned int vced_count, vcei_count;
 #define TASK_UNMAPPED_BASE						\
 	(test_thread_flag(TIF_32BIT_ADDR) ?				\
 		PAGE_ALIGN(TASK_SIZE32 / 3) : PAGE_ALIGN(TASK_SIZE / 3))
+#define TASK_SIZE_OF(tsk)						\
+	(test_thread_flag(TIF_32BIT_ADDR) ? TASK_SIZE32 : TASK_SIZE)
 #endif
 
 #define NUM_FPU_REGS	32

Re: RFC: drop support for gcc < 4.0

[Ralf Baechle]

On Tue, Aug 21, 2007 at 05:41:04PM -0300, Glauber de Oliveira Costa wrote:

> Last time I tried a mips build, it would fail the compile unless I was
> using _exactly_ 3.4.4 (I didn't tried older versions, but did try
> 3.4.6, for ex.). So I also think the 3.4 series will still have to be
> around for a while.

I don't know what broken MIPS platform you've tried.  I keep changing
between compiler versions all the time just so I can ensure builds with
older compilers keep working until we officially deciede to drop support
for them.  So the minimum compiler version for 32-bit MIPS kernels is
gcc 3.2 and for 64-bit kernel gcc 3.3.

But for sake of sanity and productivity I definately don't mind dumping
support for gcc < 4.0 or maybe even 4.1.  And while we're at it, let's
deprecate ancient binutils version as well.  A minimum version of 2.17
would be nice as I could get rid of lads of .word sillyness which is
needed to support older binutils.

  Ralf

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Dave Hansen]

On Wed, 2007-08-22 at 10:06 +0100, David Howells wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote:
> 
> > For the /proc/<pid>/pagemap code[1], we need to able to query how
> > much virtual address space a particular task has.
> 
> How does this relate to NOMMU conditions?

It probably doesn't make any sense to use the /proc/<pid>/pagemap
feature on NOMMU systems.  There are no pagetables to dump, and no
shared pages, right?

-- Dave

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Dave Hansen]

On Wed, 2007-08-22 at 18:30 +0100, Ralf Baechle wrote:
> On Tue, Aug 21, 2007 at 01:43:09PM -0600, Matthew Wilcox wrote:
> 
> > On Tue, Aug 21, 2007 at 12:38:35PM -0700, Dave Hansen wrote:
> > > I'd like to have that for other architectures.  So, add it
> > > for all the architectures that actually use "current" in 
> > > their TASK_SIZE.  For the others, just add a quick #define
> > > in sched.h to use plain old TASK_SIZE.
> > 
> > MIPS seems to do things a little differently ... Ralf, what should Dave
> > be doing here?
> > 
> > #define TASK_SIZE32     0x7fff8000UL
> > #define TASK_SIZE       0x10000000000UL
> 
> Indeed. Below patch should do the trick.

Thanks for the patch.  I'll roll it into my larger one.

-- Dave

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Dave Hansen]

On Wed, 2007-08-22 at 10:06 +0100, David Howells wrote:
> Dave Hansen <haveblue@us.ibm.com> wrote:
> > For the /proc/<pid>/pagemap code[1], we need to able to query how
> > much virtual address space a particular task has.
> 
> How does this relate to NOMMU conditions?

Were you asking about /proc/<pid>/pagemap, or about my TASK_SIZE_OF()
macro?  

/proc/<pid>/pagemap is completely implemented in task_mmu.c, so it
shouldn't show up on NOMMU systems.

As far as TASK_SIZE_OF(), it still makes sense on those systems because
they (at least m68k) still has TASK_SIZE.  Was there a particular
problem you're concerned about?  I'm not very intimately familiar with
the NOMMU code.

-- Dave

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[Matt Mackall]

On Wed, Aug 22, 2007 at 03:55:50PM -0700, Dave Hansen wrote:
> On Wed, 2007-08-22 at 10:06 +0100, David Howells wrote:
> > Dave Hansen <haveblue@us.ibm.com> wrote:
> > 
> > > For the /proc/<pid>/pagemap code[1], we need to able to query how
> > > much virtual address space a particular task has.
> > 
> > How does this relate to NOMMU conditions?
> 
> It probably doesn't make any sense to use the /proc/<pid>/pagemap
> feature on NOMMU systems.  There are no pagetables to dump, and no
> shared pages, right?

Nor is there any present/not present to report. VSS == RSS on NOMMU,
right?

So we could provide pagemap, but it's not clear it'd be very
interesting. kpagemap might be interesting, simply because of the
flags though.

-- 
Mathematics is the supreme nostalgia of our time.

Re: [RFC][PATCH] introduce TASK_SIZE_OF() for all arches

[David Howells]

Dave Hansen <haveblue@us.ibm.com> wrote:

> Were you asking about /proc/<pid>/pagemap, or about my TASK_SIZE_OF()
> macro?  

TASK_SIZE_OF().

> As far as TASK_SIZE_OF(), it still makes sense on those systems because
> they (at least m68k) still has TASK_SIZE.

Fair enough.

> Was there a particular problem you're concerned about?  I'm not very
> intimately familiar with the NOMMU code.

Since you were talking about virtual memory, I was wondering as to its
applicability for NOMMU.

David