2.6.22-rc2 built on ppc

2.6.22-rc2 built on ppc

[Elimar Riesebieter]

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

Hi,

FYI, building the kernel modules with
gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
on my powerbook (PPC) gives:

...
drivers/macintosh/therm_adt746x.c: In function 'thermostat_init':
drivers//therm_adt746x.c:617: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:618: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:619: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:620: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:621: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:622: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:623: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:624: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:625: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
drivers/macintosh/therm_adt746x.c:627: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result
...

If more info is needed, please contact me via PM, as I am not
subscribed.

Thanks for your patience
Elimar

-- 
  Never make anything simple and efficient when a way 
  can be found to make it complex and wonderful ;-)

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

Re: 2.6.22-rc2 built on ppc

[Stefan Richter]

(Adding linuxppc-dev)

Elimar Riesebieter wrote:
> Hi,
> 
> FYI, building the kernel modules with
> gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
> on my powerbook (PPC) gives:
> 
> ...
> drivers/firewire/fw-ohci.c: In function 'ar_context_tasklet':
> drivers/firewire/fw-ohci.c:357: warning: unused variable 'ohci'
> drivers/firewire/fw-ohci.c: In function 'context_release':
> drivers/firewire/fw-ohci.c:502: warning: unused variable 'card'
> drivers/firewire/fw-sbp2.c: In function 'complete_command_orb':
> drivers/firewire/fw-sbp2.c:838: warning: unused variable 'device'
> drivers/ieee1394/sbp2.c: In function 'sbp2util_remove_command_orb_pool':
> drivers/ieee1394/sbp2.c:497: warning: unused variable 'host'
> drivers/ieee1394/sbp2.c: In function 'sbp2util_mark_command_completed':
> drivers/ieee1394/sbp2.c:588: warning: unused variable 'host'
> ...


The allegedly unused variables are used in calls to dma_unmap_single(),
but only for these calls.  On PPC32, you get

	/* We do nothing. */
	#define dma_unmap_single(dev, addr, size, dir)  ((void)0)

in dma-mapping.h.  This is also the case for Linux 2.6.20.
But in Linux 2.6.19 and older, it was

	/* We do nothing. */
	#define dma_unmap_single(dev, addr, size, dir)	do { } while (0)

(Furthermore, the sbp2 driver used the pci_dma_ API in Linux 2.6.19 and
older, and fw-ohci wasn't in mainline before 2.6.22-rc1.)

I don't know what's to blame for the warnings --- new gcc versions or
the change from do { } while (0) to ((void)0)?  Either way, the compiler
should comprehend that the arguments stuffed into the dma_unmap_single
macro are _not_ unused by accident; it should stay quiet and optimize
the unused variables away if run with -Osomething.

Does somebody know more?

I'd like to avoid cluttering the drivers with __attribute((used)).


> If more info is needed, please contact me via PM, as I am not
> subscribed.

We usually keep posters Cc'ed in list replies, at least on development
lists where bug reports are welcomed.
-- 
Stefan Richter
-=====-=-=== -=-= =-=--
http://arcgraph.de/sr/

Re: 2.6.22-rc2 built on ppc

[Stefan Richter]

I wrote:
> The allegedly unused variables are used in calls to dma_unmap_single(),
> but only for these calls.

and a call to dma_unmap_sg().

> On PPC32, you get
> 
> 	/* We do nothing. */
> 	#define dma_unmap_single(dev, addr, size, dir)  ((void)0)
> 
> in dma-mapping.h.  This is also the case for Linux 2.6.20.
> But in Linux 2.6.19 and older, it was
> 
> 	/* We do nothing. */
> 	#define dma_unmap_single(dev, addr, size, dir)	do { } while (0)
...
> I don't know what's to blame for the warnings --- new gcc versions or
> the change from do { } while (0) to ((void)0)?
...

Ditto for dma_unmap_sg().
-- 
Stefan Richter
-=====-=-=== -=-= =-=--
http://arcgraph.de/sr/

Re: 2.6.22-rc2 built on ppc

[Arnd Bergmann]

On Sunday 20 May 2007, Stefan Richter wrote:
> I don't know what's to blame for the warnings --- new gcc versions or
> the change from do { } while (0) to ((void)0)? =A0Either way, the compiler
> should comprehend that the arguments stuffed into the dma_unmap_single
> macro are _not_ unused by accident; it should stay quiet and optimize
> the unused variables away if run with -Osomething.

There is not much that the compiler can do by itself, since the macro
expansion happens in the preprocessor.

I think the best solution would be to replace the macros with
inline functions, so that the compiler can see them. This will
also give gcc the chance to do type checking on the arguments.

	Arnd <><

Re: 2.6.22-rc2 built on ppc

[Segher Boessenkool]

>> I don't know what's to blame for the warnings --- new gcc versions or
>> the change from do { } while (0) to ((void)0)? =A0Either way, the=20
>> compiler
>> should comprehend that the arguments stuffed into the =
dma_unmap_single
>> macro are _not_ unused by accident; it should stay quiet and optimize
>> the unused variables away if run with -Osomething.
>
> There is not much that the compiler can do by itself, since the macro
> expansion happens in the preprocessor.

Even if the compiler could see that the variables are
used as macro arguments, this doesn't automatically
equate to it being able to infer the variables are
unused on purpose.

> I think the best solution would be to replace the macros with
> inline functions, so that the compiler can see them.

This should shut up the warnings, yes...

> This will
> also give gcc the chance to do type checking on the arguments.

...and it is a good idea no matter what.


Segher

Re: 2.6.22-rc2 built on ppc

[Stefan Richter]

Segher Boessenkool wrote:
>>> I don't know what's to blame for the warnings --- new gcc versions or
>>> the change from do { } while (0) to ((void)0)?  Either way, the compiler
>>> should comprehend that the arguments stuffed into the dma_unmap_single
>>> macro are _not_ unused by accident; it should stay quiet and optimize
>>> the unused variables away if run with -Osomething.
>>
>> There is not much that the compiler can do by itself, since the macro
>> expansion happens in the preprocessor.
> 
> Even if the compiler could see that the variables are
> used as macro arguments, this doesn't automatically
> equate to it being able to infer the variables are
> unused on purpose.

Strange.  I believe we had code before with variables that were only
used in macros that expanded to <nil>, notably debug logging macros
which were usually configured out.  Perhaps I'm mistaken.
-- 
Stefan Richter
-=====-=-=== -=-= =-=--
http://arcgraph.de/sr/

Re: 2.6.22-rc2 built on ppc

[Geert Uytterhoeven]

On Sun, 20 May 2007, Stefan Richter wrote:
> Segher Boessenkool wrote:
> >>> I don't know what's to blame for the warnings --- new gcc versions or
> >>> the change from do { } while (0) to ((void)0)?  Either way, the compiler
> >>> should comprehend that the arguments stuffed into the dma_unmap_single
> >>> macro are _not_ unused by accident; it should stay quiet and optimize
> >>> the unused variables away if run with -Osomething.
> >>
> >> There is not much that the compiler can do by itself, since the macro
> >> expansion happens in the preprocessor.
> > 
> > Even if the compiler could see that the variables are
> > used as macro arguments, this doesn't automatically
> > equate to it being able to infer the variables are
> > unused on purpose.
> 
> Strange.  I believe we had code before with variables that were only
> used in macros that expanded to <nil>, notably debug logging macros
> which were usually configured out.  Perhaps I'm mistaken.

No, they were unused by the macro when DEBUG was not set.
Only when dev_dbg() was converted from a macro to a static inline function
did they start to be used (according to the compiler) all the time.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- Sony Network and Software Technology Center Europe (NSCE)
Geert.Uytterhoeven@sonycom.com ------- The Corporate Village, Da Vincilaan 7-D1
Voice +32-2-7008453 Fax +32-2-7008622 ---------------- B-1935 Zaventem, Belgium