public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Fix the sign of the result of a conditional expression
@ 2007-08-15 21:02 Chuck Lever
  2007-08-15 21:02 ` [PATCH] Eliminate result signage problem in asm-x86_64/bitops.h Chuck Lever
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Lever @ 2007-08-15 21:02 UTC (permalink / raw)
  To: andi; +Cc: linux-kernel

In include/asm-x86_64/bitops.h, the find_{first,next,first_zero,next_zero}_bit
macros return a result type that depends on the width of the "size" argument.
The type of both arms of a conditional expression should always be the same.

I changed the return type of __scanbit() to match the return type of the
x86_64 find_*_bit() functions.

-- 
corporate:    <chuck dot lever at oracle dot com>

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [PATCH] Eliminate result signage problem in asm-x86_64/bitops.h
  2007-08-15 21:02 [PATCH] Fix the sign of the result of a conditional expression Chuck Lever
@ 2007-08-15 21:02 ` Chuck Lever
  2007-08-15 22:23   ` Andi Kleen
  0 siblings, 1 reply; 4+ messages in thread
From: Chuck Lever @ 2007-08-15 21:02 UTC (permalink / raw)
  To: andi; +Cc: linux-kernel

The return type of __scanbit() doesn't match the return type of
find_{first,next}_bit().  Thus when you construct something like
this:

   boolean ? __scanbit() : find_first_bit()

you get an unsigned long result if "boolean" is true, and a signed
long result if "boolean" is false.

In file included from /home/cel/src/linux/include/linux/mmzone.h:15,
                 from /home/cel/src/linux/include/linux/gfp.h:4,
                 from /home/cel/src/linux/include/linux/slab.h:14,
                 from /home/cel/src/linux/include/linux/percpu.h:5,
                 from
/home/cel/src/linux/include/linux/rcupdate.h:41,
                 from /home/cel/src/linux/include/linux/dcache.h:10,
                 from /home/cel/src/linux/include/linux/fs.h:275,
                 from /home/cel/src/linux/fs/nfs/sysctl.c:9:
/home/cel/src/linux/include/linux/nodemask.h: In function
‘__first_node’:
/home/cel/src/linux/include/linux/nodemask.h:229: warning: signed and
unsigned type in conditional expression
/home/cel/src/linux/include/linux/nodemask.h: In function
‘__next_node’:
/home/cel/src/linux/include/linux/nodemask.h:235: warning: signed and
unsigned type in conditional expression
/home/cel/src/linux/include/linux/nodemask.h: In function
‘__first_unset_node’:
/home/cel/src/linux/include/linux/nodemask.h:253: warning: signed and
unsigned type in conditional expression

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---

 include/asm-x86_64/bitops.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-x86_64/bitops.h b/include/asm-x86_64/bitops.h
index d4dbbe5..1d7d9b4 100644
--- a/include/asm-x86_64/bitops.h
+++ b/include/asm-x86_64/bitops.h
@@ -260,7 +260,7 @@ extern long find_first_bit(const unsigned long * addr, unsigned long size);
 extern long find_next_bit(const unsigned long * addr, long size, long offset);
 
 /* return index of first bet set in val or max when no bit is set */
-static inline unsigned long __scanbit(unsigned long val, unsigned long max)
+static inline long __scanbit(unsigned long val, unsigned long max)
 {
 	asm("bsfq %1,%0 ; cmovz %2,%0" : "=&r" (val) : "r" (val), "r" (max));
 	return val;


^ permalink raw reply related	[flat|nested] 4+ messages in thread

* Re: [PATCH] Eliminate result signage problem in asm-x86_64/bitops.h
  2007-08-15 21:02 ` [PATCH] Eliminate result signage problem in asm-x86_64/bitops.h Chuck Lever
@ 2007-08-15 22:23   ` Andi Kleen
  2007-08-15 22:42     ` Chuck Lever
  0 siblings, 1 reply; 4+ messages in thread
From: Andi Kleen @ 2007-08-15 22:23 UTC (permalink / raw)
  To: Chuck Lever; +Cc: andi, linux-kernel

On Wed, Aug 15, 2007 at 05:02:47PM -0400, Chuck Lever wrote:
> The return type of __scanbit() doesn't match the return type of
> find_{first,next}_bit().  Thus when you construct something like
> this:
> 
>    boolean ? __scanbit() : find_first_bit()

Why would you want to write this?  What is boolean?
Do they have different arguments?

It's on my todo list for some time to special case
f_f_b() and friends for smaller arguments. Would
that eliminate this construct?

-Andi

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Eliminate result signage problem in asm-x86_64/bitops.h
  2007-08-15 22:23   ` Andi Kleen
@ 2007-08-15 22:42     ` Chuck Lever
  0 siblings, 0 replies; 4+ messages in thread
From: Chuck Lever @ 2007-08-15 22:42 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-kernel

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

I apologize for sending a separate cover letter for a single patch.

Andi Kleen wrote:
> On Wed, Aug 15, 2007 at 05:02:47PM -0400, Chuck Lever wrote:
>> The return type of __scanbit() doesn't match the return type of
>> find_{first,next}_bit().  Thus when you construct something like
>> this:
>>
>>    boolean ? __scanbit() : find_first_bit()
> 
> Why would you want to write this?  What is boolean?
> Do they have different arguments?

So here's the definition of the x86_64 find_first_bit() macro, straight 
from include/x86_64/bitops.h:

#define find_first_bit(addr,size) \
((__builtin_constant_p(size) && (size) <= BITS_PER_LONG ? \
   (__scanbit(*(unsigned long *)addr,(size))) : \
   find_first_bit(addr,size)))

In this case "boolean" is:

    __builtin_constant_p(size) && (size) <= BITS_PER_LONG

the first arm of the conditional is:

    __scanbit(*(unsigned long *)addr,(size))

the second arm of the conditional is:

    find_first_bit(addr,size)

(this is the "function" version of find_first_bit, not the macro that's 
being defined.  The naming here is unfortunately confusing).

Thus, roughly speaking, when the type of "size" is smaller than a long, 
the macro's return type evaluates to unsigned long.  If "size" is larger 
than a long, the macro's return type evaluates to signed long.

By making the return type of __scanbit() an unsigned long, both arms of 
the conditional evaluate to the same result type.

> It's on my todo list for some time to special case
> f_f_b() and friends for smaller arguments. Would
> that eliminate this construct?

Well, I can only assume what you mean by this, but I think that would 
address the problem.

My real interest here is to eliminate a whole lot of compiler noise when 
I enable -Wsign-compare for certain parts of the kernel.

[-- Attachment #2: chuck.lever.vcf --]
[-- Type: text/x-vcard, Size: 290 bytes --]

begin:vcard
fn:Chuck Lever
n:Lever;Chuck
org:Oracle Corporation;Corporate Architecture: Linux Projects Group
adr:;;1015 Granger Avenue;Ann Arbor;MI;48104;USA
title:Principal Member of Staff
tel;work:+1 248 614 5091
x-mozilla-html:FALSE
url:http://oss.oracle.com/~cel
version:2.1
end:vcard


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2007-08-15 22:45 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-08-15 21:02 [PATCH] Fix the sign of the result of a conditional expression Chuck Lever
2007-08-15 21:02 ` [PATCH] Eliminate result signage problem in asm-x86_64/bitops.h Chuck Lever
2007-08-15 22:23   ` Andi Kleen
2007-08-15 22:42     ` Chuck Lever

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox