2.6.23-rc3-git3 make warnings

2.6.23-rc3-git3 make warnings

[Jarek Poplawski]

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

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

[-- Attachment #2: .config.bz2 --]
[-- Type: application/octet-stream, Size: 7184 bytes --]

[Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

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

Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>

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

Index: linux-2.6.23-rc3-git3/drivers/acpi/ec.c
===================================================================
--- linux-2.6.23-rc3-git3.orig/drivers/acpi/ec.c
+++ linux-2.6.23-rc3-git3/drivers/acpi/ec.c
@@ -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;
 	}

Re: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Alexey Starikovskiy]

WANG Cong wrote:
> 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: WANG Cong <xiyou.wangcong@gmail.com>
>
>   
ACK

Thanks,
Alex
> ---
>  drivers/acpi/ec.c |    4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> Index: linux-2.6.23-rc3-git3/drivers/acpi/ec.c
> ===================================================================
> --- linux-2.6.23-rc3-git3.orig/drivers/acpi/ec.c
> +++ linux-2.6.23-rc3-git3/drivers/acpi/ec.c
> @@ -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;
>  	}
>   

Re: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Al Viro]

On Tue, Aug 21, 2007 at 07:14:49PM +0400, Alexey Starikovskiy wrote:
> WANG Cong wrote:
> > 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 <viro@zeniv.linux.org.uk>
---
diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval.c
index ab65b2c..f39fbc6 100644
--- a/drivers/acpi/namespace/nsxfeval.c
+++ b/drivers/acpi/namespace/nsxfeval.c
@@ -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)
 {
diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
index b5cca5d..3d7ab9e 100644
--- a/include/acpi/acpixf.h
+++ b/include/acpi/acpixf.h
@@ -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);
 
diff --git a/include/acpi/acstruct.h b/include/acpi/acstruct.h
index aeb4498..8848265 100644
--- a/include/acpi/acstruct.h
+++ b/include/acpi/acstruct.h
@@ -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 {

Re: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Alexey Starikovskiy]

Al Viro wrote:
> On Tue, Aug 21, 2007 at 07:14:49PM +0400, Alexey Starikovskiy wrote:
>   
>> WANG Cong wrote:
>>     
>>> 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.
>>     
>
>   
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.

Regards,
Alex.
> Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
> ---
> diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval.c
> index ab65b2c..f39fbc6 100644
> --- a/drivers/acpi/namespace/nsxfeval.c
> +++ b/drivers/acpi/namespace/nsxfeval.c
> @@ -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)
>  {
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
> index b5cca5d..3d7ab9e 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -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);
>  
> diff --git a/include/acpi/acstruct.h b/include/acpi/acstruct.h
> index aeb4498..8848265 100644
> --- a/include/acpi/acstruct.h
> +++ b/include/acpi/acstruct.h
> @@ -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 {
>   

Re: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Al Viro]

On Tue, Aug 21, 2007 at 07:22:51PM +0400, Alexey Starikovskiy wrote:
> 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.

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

RE: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Brown, Len]

>On Tue, Aug 21, 2007 at 07:22:51PM +0400, Alexey Starikovskiy wrote:
>> 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.
>
>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.

I've actually never had anybody say no when I asked.
And I've had some people who play laywers on TV tell me
this is not strictly necessary, but other people who play laywers
on TV tell me it is best to ask, so I do.

thanks,
-Len

Re: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Al Viro]

On Wed, Aug 22, 2007 at 08:59:48PM -0400, Brown, Len wrote:
> 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.

You have it.

Re: [Git Patch] ACPI: Fix a warning of discarding qualifiers from pointer target type

[Jarek Poplawski]

On Tue, Aug 21, 2007 at 04:18:20PM +0100, Al Viro wrote:
> On Tue, Aug 21, 2007 at 07:14:49PM +0400, Alexey Starikovskiy wrote:
> > WANG Cong wrote:
> > > 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 <viro@zeniv.linux.org.uk>
> ---
> diff --git a/drivers/acpi/namespace/nsxfeval.c b/drivers/acpi/namespace/nsxfeval.c
> index ab65b2c..f39fbc6 100644
> --- a/drivers/acpi/namespace/nsxfeval.c
> +++ b/drivers/acpi/namespace/nsxfeval.c
> @@ -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)
>  {
> diff --git a/include/acpi/acpixf.h b/include/acpi/acpixf.h
> index b5cca5d..3d7ab9e 100644
> --- a/include/acpi/acpixf.h
> +++ b/include/acpi/acpixf.h
> @@ -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);
>  
> diff --git a/include/acpi/acstruct.h b/include/acpi/acstruct.h
> index aeb4498..8848265 100644
> --- a/include/acpi/acstruct.h
> +++ b/include/acpi/acstruct.h
> @@ -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 {
> 

So, it looks like this patch (or at least its -mm version) is working.

Now there is 'only' like this (there could be something new, because
I've forgotten to mention this yesterday's log was the second make,
after removing some small testing patch; here it's after make clean;
.config is the same; gcc 3.2.3):

sed: -e expression #1, char 154: Unknown option to 's'
kernel/power/pm.c:205: warning: `pm_register' is deprecated (declared at kernel/power/pm.c:64)
kernel/power/pm.c:205: warning: `pm_register' is deprecated (declared at kernel/power/pm.c:64)
kernel/power/pm.c:206: warning: `pm_send_all' is deprecated (declared at kernel/power/pm.c:180)
kernel/power/pm.c:206: warning: `pm_send_all' is deprecated (declared at kernel/power/pm.c:180)
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'
include/asm/processor.h: In function `native_get_debugreg':
include/asm/processor.h:524: warning: asm operand 0 probably doesn't match constraints
include/asm/processor.h: In function `native_set_debugreg':
include/asm/processor.h:551: warning: asm operand 0 probably doesn't match constraints
Root device is (8, 1)
Setup is 11036 bytes (padded to 11264 bytes).
System is 2428 kB

Cheers,
Jarek P.

PS: does somebody here remember these old good times:
real    56m19.454s
user    53m38.580s
sys     2m7.610s

Re: 2.6.23-rc3-git3 make warnings

[WANG Cong]

On Tue, Aug 21, 2007 at 03:20:38PM +0200, Jarek Poplawski wrote:
>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'
				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

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?

-- 
_   /|
\'o.O'
=(___)=
   U    ack!

Re: 2.6.23-rc3-git3 make warnings

[Greg KH]

On Wed, Aug 22, 2007 at 12:17:23AM +0800, WANG Cong wrote:
> On Tue, Aug 21, 2007 at 03:20:38PM +0200, Jarek Poplawski wrote:
> >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'
> 				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> 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?

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

thanks,

greg k-h

Re: 2.6.23-rc3-git3 make warnings

[Adrian Bunk]

On Tue, Aug 21, 2007 at 09:44:29AM -0700, Greg KH wrote:
> On Wed, Aug 22, 2007 at 12:17:23AM +0800, WANG Cong wrote:
> > On Tue, Aug 21, 2007 at 03:20:38PM +0200, Jarek Poplawski wrote:
> > >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'
> > 				^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> > 
> > 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?
> 
> gcc bug, I have a patch for this queued up.

No, gcc is all right.

The problem is that with CONFIG_PM=y, CONFIG_PM_SLEEP=n 
device_may_wakeup() is an empty macro, and the pdev usage is in this 
case removed by the preprocessor and therefore invisible to the 
compiler.

> thanks,
> 
> greg k-h

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.23-rc3-git3 make warnings

[Randy Dunlap]

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

What gcc version?  I don't get the arch_ warnings in drivers/pci/msi.c.

---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***

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

[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

[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

[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

[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]

> 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

[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

[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: 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

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

[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

[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

[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

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

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

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

[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

[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: 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/