Re: 2.6.22-rc2 built on ppc

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

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

2.6.22-rc2 built on ppc

[Elimar Riesebieter]

[-- Attachment #1: Type: text/plain, Size: 678 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:

...
fs/udf/balloc.c: In function 'udf_table_new_block':
fs/udf/balloc.c:747: warning: 'goal_eloc.logicalBlockNum' may be used uninitialized in this function
fs/udf/super.c: In function 'udf_fill_super':
fs/udf/super.c:1359: warning: 'ino.partitionReferenceNum' may be used uninitialized in this function
...

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

2.6.22-rc2 built on ppc

[Elimar Riesebieter]

[-- Attachment #1.1: Type: text/plain, Size: 693 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:

...
fs/nfsd/nfs4acl.c: In function '_posix_to_nfsv4_one':
fs/nfsd/nfs4acl.c:227: warning: 'pas.owner' may be used uninitialized in this function
fs/nfsd/nfs4acl.c:227: warning: 'pas.group' may be used uninitialized in this function
fs/nfsd/nfs4acl.c:227: warning: 'pas.other' may be used uninitialized in this function
...

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 #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 286 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/

[-- Attachment #3: Type: text/plain, Size: 140 bytes --]

_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.6.22-rc2 built on ppc

[Neil Brown]

On Sunday May 20, riesebie@lxtec.de 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:
> 
> ...
> fs/nfsd/nfs4acl.c: In function '_posix_to_nfsv4_one':
> fs/nfsd/nfs4acl.c:227: warning: 'pas.owner' may be used uninitialized in this function
> fs/nfsd/nfs4acl.c:227: warning: 'pas.group' may be used uninitialized in this function
> fs/nfsd/nfs4acl.c:227: warning: 'pas.other' may be used uninitialized in this function
> ...

Yes....
The reality is that these fields will not be used uninitialised.  This
is because every 'posix_acl' always has an ACL_USER_OBJ, and
ACL_GROUP_OBJ, and an ACL_OTHER.  Isn't it Bruce ??

Maybe we could set all three to zero at the top of
summarize_posix_acl, but doing that just to get the compiler to be
quite is sometimes frowned upon.

Bruce?  Do you have an opinion?

NeilBrown

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: 2.6.22-rc2 built on ppc

[J. Bruce Fields]

On Tue, May 22, 2007 at 03:40:50PM +1000, Neil Brown wrote:
> On Sunday May 20, riesebie@lxtec.de wrote:
> > fs/nfsd/nfs4acl.c: In function '_posix_to_nfsv4_one':
> > fs/nfsd/nfs4acl.c:227: warning: 'pas.owner' may be used uninitialized in this function
> > fs/nfsd/nfs4acl.c:227: warning: 'pas.group' may be used uninitialized in this function
> > fs/nfsd/nfs4acl.c:227: warning: 'pas.other' may be used uninitialized in this function
> 
> Yes....
> The reality is that these fields will not be used uninitialised.  This
> is because every 'posix_acl' always has an ACL_USER_OBJ, and
> ACL_GROUP_OBJ, and an ACL_OTHER.  Isn't it Bruce ??

Yeah, note the:

	/* We assume the acl has been verified with posix_acl_valid. */

at the top of _posix_to_nfsv4_one()--as long as that's true, the
warnings are bogus.  Of course, this isn't the sort of thing you'd
expect a compiler to know.  But probably it should know it can't know,
and be quiet.

> Maybe we could set all three to zero at the top of
> summarize_posix_acl, but doing that just to get the compiler to be
> quite is sometimes frowned upon.
> 
> Bruce?  Do you have an opinion?

You've summed it up.

I hate the compile noise too.  If people really wanted the
initialization there, and didn't think it would make the code more
confusing (e.g. by implying the rest of the code should also be dealing
with the case when the ACL_USER_OBJ, ACL_GROUP, or ACL_OTHER entries
weren't there), then I'd be OK with adding it.  Though I'm not
particularly interested in another flamewar about whose fault these
warnings are.

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

2.6.22-rc2 built on ppc

[Elimar Riesebieter]

[-- Attachment #1.1: Type: text/plain, Size: 815 bytes --]

Hi,

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

...
drivers/cpufreq/cpufreq.c: In function 'cpufreq_add_dev':
drivers/cpufreq/cpufreq.c:829: warning: ignoring return value of 'sysfs_create_file', declared with attribute warn_unused_result
drivers/cpufreq/cpufreq.c:833: warning: ignoring return value of 'sysfs_create_file', declared with attribute warn_unused_result
drivers/cpufreq/cpufreq.c:835: warning: ignoring return value of 'sysfs_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 #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 147 bytes --]

_______________________________________________
Cpufreq mailing list
Cpufreq@lists.linux.org.uk
http://lists.linux.org.uk/mailman/listinfo/cpufreq

2.6.22-rc2 built on ppc

[Elimar Riesebieter]

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

Hi,

FYI, building the kernel with
gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
on my powerbook (PPC) gives:
...
ipc/msg.c: In function 'sys_msgctl':
ipc/msg.c:390: warning: 'setbuf.qbytes' may be used uninitialized in this function
ipc/msg.c:390: warning: 'setbuf.uid' may be used uninitialized in this function
ipc/msg.c:390: warning: 'setbuf.gid' may be used uninitialized in this function
ipc/msg.c:390: warning: 'setbuf.mode' may be used uninitialized in this function
ipc/sem.c: In function 'sys_semctl':
ipc/sem.c:861: warning: 'setbuf.uid' may be used uninitialized in this function
ipc/sem.c:861: warning: 'setbuf.gid' may be used uninitialized in this function
ipc/sem.c:861: warning: 'setbuf.mode' may be used uninitialized in this function
...

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

[Patrick McHardy]

Elimar Riesebieter wrote:
> FYI, building the kernel with
> gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7)
> on my powerbook (PPC) gives:
> ...
> ipc/msg.c: In function 'sys_msgctl':
> ipc/msg.c:390: warning: 'setbuf.qbytes' may be used uninitialized in this function
> ipc/msg.c:390: warning: 'setbuf.uid' may be used uninitialized in this function
> ipc/msg.c:390: warning: 'setbuf.gid' may be used uninitialized in this function
> ipc/msg.c:390: warning: 'setbuf.mode' may be used uninitialized in this function
> ipc/sem.c: In function 'sys_semctl':
> ipc/sem.c:861: warning: 'setbuf.uid' may be used uninitialized in this function
> ipc/sem.c:861: warning: 'setbuf.gid' may be used uninitialized in this function
> ipc/sem.c:861: warning: 'setbuf.mode' may be used uninitialized in this function


Probably just another bogus gcc warning. In any case it has nothing
to do with netfilter.

2.6.22-rc2 built on ppc

[Elimar Riesebieter]

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

Hi,

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

...
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/keyboard/Kconfig:170:warning: 'select' used by config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
drivers/input/mouse/Kconfig:182:warning: 'select' used by config symbol 'MOUSE_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'
...

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