From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: 2007-05-20 16:46:53
(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/
From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: 2007-05-20 16:02:01
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/
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 <><
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
quoted
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.
From: Stefan Richter <stefanr@s5r6.in-berlin.de> Date: 2007-05-20 18:40:40
Segher Boessenkool wrote:
quoted
quoted
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/
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