2.6.23-rc3-git3 make warnings

Fix this warning:

drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type

(I don't know whether this fix hits the real problem.)

Signed-off-by WANG Cong <[email protected]>

---
 drivers/acpi/ec.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: linux-2.6.23-rc3-git3/drivers/acpi/ec.c
===================================================================

drivers/acpi/ec.c +2 -2

@@ -869,8 +869,8 @@ int __init acpi_ec_ecdt_probe(void)
 		boot_ec->handle = ACPI_ROOT_OBJECT;
 	} else {
 		printk(KERN_DEBUG PREFIX "Look up EC in DSDT\n");
-		status = acpi_get_devices(ec_device_ids[0].id, ec_parse_device,
-						boot_ec, NULL);
+		status = acpi_get_devices((char *)ec_device_ids[0].id,
+						ec_parse_device, boot_ec, NULL);
 		if (ACPI_FAILURE(status))
 			goto error;
 	}

Quoted 7 lines · WANG Cong

Fix this warning:

drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type

(I don't know whether this fix hits the real problem.)

It is safe to give acpi_get_devices() const string, as it should not modify it in any condition.

Quoted 7 lines · Alexey Starikovskiy

Quoted 5 lines · WANG Cong

Fix this warning:

drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type

Quoted 6 lines

Quoted 3 lines

(I don't know whether this fix hits the real problem.)

It is safe to give acpi_get_devices() const string, as it should not modify it in any condition.

Signed-off-by Al Viro <[email protected]>

---

drivers/acpi/namespace/nsxfeval.c +1 -1

index ab65b2c..f39fbc6 100644
@@ -540,7 +540,7 @@ acpi_ns_get_device_callback(acpi_handle obj_handle,
  ******************************************************************************/
 
 acpi_status
-acpi_get_devices(char *HID,
+acpi_get_devices(const char *HID,
 		 acpi_walk_callback user_function,
 		 void *context, void **return_value)
 {

include/acpi/acpixf.h +1 -1

index b5cca5d..3d7ab9e 100644
@@ -130,7 +130,7 @@ acpi_walk_namespace(acpi_object_type type,
 		    void *context, void **return_value);
 
 acpi_status
-acpi_get_devices(char *HID,
+acpi_get_devices(const char *HID,
 		 acpi_walk_callback user_function,
 		 void *context, void **return_value);
 

include/acpi/acstruct.h +1 -1

index aeb4498..8848265 100644
@@ -146,7 +146,7 @@ struct acpi_init_walk_info {
 struct acpi_get_devices_info {
 	acpi_walk_callback user_function;
 	void *context;
-	char *hid;
+	const char *hid;
 };
 
 union acpi_aml_operands {

Yes, that is the proper solution with a single drawback:
it touches ACPICA dual-licensed code and would take ages to commit, and Len would probably ask you to give permission to re-license it under BSD.

Quoted 3 lines

Yes, that is the proper solution with a single drawback:
it touches ACPICA dual-licensed code and would take ages to commit, and Len would probably ask you to give permission to

re-license it under

Quoted 1 line

BSD.

The latter is certainly not a problem (assuming that it's non-trivial enough to be copyrightable, in the first place).

The dual license is at the top of the file.
I just need to know when you touch one of these dual-license files that Intel has your permission to ship your change to folks we send the same file to under the BSD-style non-GPL license. eg. BSD, Solaris and HPUX uses this same ACPICA files -- though in a different format.

Quoted 10 lines · Alexey Starikovskiy

Quoted 7 lines · WANG Cong

Fix this warning:

drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of `acpi_get_devices' discards qualifiers from pointer target type

(I don't know whether this fix hits the real problem.)

It is safe to give acpi_get_devices() const string, as it should not modify it in any condition.

Signed-off-by Al Viro <[email protected]>

---

drivers/acpi/namespace/nsxfeval.c +1 -1

index ab65b2c..f39fbc6 100644
@@ -540,7 +540,7 @@ acpi_ns_get_device_callback(acpi_handle obj_handle,
  ******************************************************************************/
 
 acpi_status
-acpi_get_devices(char *HID,
+acpi_get_devices(const char *HID,
 		 acpi_walk_callback user_function,
 		 void *context, void **return_value)
 {

include/acpi/acpixf.h +1 -1

index b5cca5d..3d7ab9e 100644
@@ -130,7 +130,7 @@ acpi_walk_namespace(acpi_object_type type,
 		    void *context, void **return_value);
 
 acpi_status
-acpi_get_devices(char *HID,
+acpi_get_devices(const char *HID,
 		 acpi_walk_callback user_function,
 		 void *context, void **return_value);
 

include/acpi/acstruct.h +0 -0

index aeb4498..8848265 100644

Here are some more of, probably well-known, warnings with attached testing-only .config.

Regards,
Jarek P.

sed: -e expression #1, char 154: Unknown option to 's'
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of acpi_get_devices' discards qualifiers from pointer target type drivers/pci/search.c: In function pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480) drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) 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 In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'

Quoted 7 lines · Jarek Poplawski

Here are some more of, probably well-known, warnings with attached testing-only .config.

Regards,
Jarek P.

Quoted 16 lines

sed: -e expression #1, char 154: Unknown option to 's'
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of acpi_get_devices' discards qualifiers from pointer target type drivers/pci/search.c: In function pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480) drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) 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 In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'

				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This warning is suspicious. In fact, 'pdev' is used when CONFIG_PM is defined. See the following:

<snip>

                if (device_may_wakeup(&pdev->dev))
                        ohci->hc_control |= OHCI_CTRL_RWC;

<snip>

Or a bug of gcc?

Quoted 29 lines · WANG Cong

Quoted 7 lines · Jarek Poplawski

Here are some more of, probably well-known, warnings with attached testing-only .config.

Regards,
Jarek P.

Quoted 16 lines

sed: -e expression #1, char 154: Unknown option to 's'
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of acpi_get_devices' discards qualifiers from pointer target type drivers/pci/search.c: In function pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480) drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) 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 In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'

				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This warning is suspicious. In fact, 'pdev' is used when CONFIG_PM is defined. See the following:

Quoted 6 lines

<snip>

                if (device_may_wakeup(&pdev->dev))
                        ohci->hc_control |= OHCI_CTRL_RWC;

<snip>

Or a bug of gcc?

gcc bug, I have a patch for this queued up.

thanks,

greg k-h

Quoted 29 lines · WANG Cong

Quoted 7 lines · Jarek Poplawski

Here are some more of, probably well-known, warnings with attached testing-only .config.

Regards,
Jarek P.

Quoted 16 lines

sed: -e expression #1, char 154: Unknown option to 's'
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of acpi_get_devices' discards qualifiers from pointer target type drivers/pci/search.c: In function pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480) drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) 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 In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'

				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This warning is suspicious. In fact, 'pdev' is used when CONFIG_PM is defined. See the following:

Quoted 6 lines

<snip>

                if (device_may_wakeup(&pdev->dev))
                        ohci->hc_control |= OHCI_CTRL_RWC;

<snip>

Or a bug of gcc?

gcc bug, I have a patch for this queued up.

thanks,

greg k-h

Here are some more of, probably well-known, warnings with attached testing-only .config.

Regards,
Jarek P.

sed: -e expression #1, char 154: Unknown option to 's'
drivers/acpi/ec.c: In function `acpi_ec_ecdt_probe':
drivers/acpi/ec.c:873: warning: passing arg 1 of acpi_get_devices' discards qualifiers from pointer target type drivers/pci/search.c: In function pci_find_slot':
drivers/pci/search.c:99: warning: `pci_find_device' is deprecated (declared at include/linux/pci.h:480) drivers/pci/search.c: At top level:
drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:437: warning: pci_find_device' is deprecated (declared at drivers/pci/search.c:244) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) drivers/pci/search.c:438: warning: pci_find_slot' is deprecated (declared at drivers/pci/search.c:96) 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 In file included from drivers/usb/host/ohci-hcd.c:859:
drivers/usb/host/ohci-pci.c: In function `ohci_pci_start':
drivers/usb/host/ohci-pci.c:202: warning: unused variable `pdev'
Root device is (8, 1)
Setup is 11036 bytes (padded to 11264 bytes).
System is 2428 kB

Quoted 7 lines · 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.

~Randy

Quoted 11 lines · Randy Dunlap

Quoted 7 lines · 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.

Quoted 25 lines · Adrian Bunk

Quoted 11 lines · Randy Dunlap

Quoted 7 lines · 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.

Quoted 1 line

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.

Quoted 1 line

From my point of view, gcc 4 compilers have been something of a development

thing as far as the ARM architecture goes.
...

Russell King

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

Are there any architectures still requiring a gcc < 4.0 ?

Quoted 1 line · Adrian Bunk

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.

Quoted 3 lines

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.

Quoted 2 lines

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?

Quoted 4 lines · Chris Wedgwood

Quoted 1 line · Adrian Bunk

Are there any architectures still requiring a gcc < 4.0 ?

Quoted 2 lines

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.

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.

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

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.

Quoted 1 line · Adrian Bunk

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.

Quoted 3 lines

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

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.

Quoted 2 lines

Bogus warnings should be relatively harmless.

How many kernel developers use such old gcc versions?

Quoted 4 lines · Adrian Bunk

Quoted 2 lines

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

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

Quoted 2 lines · Adrian Bunk

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

How could anybody know?

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

Quoted 1 line

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

Quoted 5 lines · Segher Boessenkool

Quoted 1 line

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...

Quoted 4 lines

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.

Quoted 1 line

Segher

cu
Adrian

Quoted 11 lines · Adrian Bunk

Quoted 5 lines · Segher Boessenkool

Quoted 1 line

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

Quoted 5 lines

Quoted 1 line

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...

Quoted 4 lines

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.

Quoted 1 line

Quoted 1 line

Quoted 1 line

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

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!?

Quoted 3 lines · Oliver Pinter

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.

Quoted 7 lines · Jan Engelhardt

Quoted 3 lines · Oliver Pinter

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!

Quoted 7 lines · Jarek Poplawski

Quoted 6 lines · Jan Engelhardt

Quoted 3 lines · Oliver Pinter

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!?

Quoted 3 lines

Quoted 1 line

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?

Quoted 7 lines · Jarek Poplawski

Quoted 6 lines · Jan Engelhardt

Quoted 3 lines · Oliver Pinter

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!?

Quoted 3 lines

Quoted 1 line

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?

Quoted 3 lines

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.