linux-mips
[Top] [All Lists]

Re: gcc warning in my trace_benchmark() code

To: Steven Rostedt <rostedt@goodmis.org>
Subject: Re: gcc warning in my trace_benchmark() code
From: David Daney <ddaney.cavm@gmail.com>
Date: Thu, 05 Jun 2014 14:56:24 -0700
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=PTOsppSYOIeYvFvMLIMkHW+rFdK2qOWjn+BucvzmQtE=; b=YqF3X+tyRZaUtUGySGejZNKeaXbD+46EnmC95b5czOxsNivo0g7dcIn23e0B3LlVZn 1NYNtBOTSqs/N1ZsPVt2gODaYXr/pqrcQuYizVYFt9XgQipoZfnulADwvLJ4IqcvCzLt 4CtCN1rNoCczIiXvVMP3q8FBhw7QWuHeGsUJmy98Acbosr+WgXQuVUplM22SkgnQ/f6b CLO8QVdG6lXroj0nut4P6T2y171ej+NAcBujGQIfB1iWWi+EcJjRprD5e5hl5WgSjvIw OCkxZ4FXaPdmWddj3SQTLCvWeiWODLst0hMnPjEd+lhp+Eu2eo+8H1zjc5ZpDTabLXS1 iwlA==
In-reply-to: <20140605145339.57c5be79@gandalf.local.home>
List-archive: <http://www.linux-mips.org/archives/linux-mips/>
List-help: <mailto:ecartis@linux-mips.org?Subject=help>
List-id: linux-mips <linux-mips.eddie.linux-mips.org>
List-owner: <mailto:ralf@linux-mips.org>
List-post: <mailto:linux-mips@linux-mips.org>
List-software: Ecartis version 1.0.0
List-subscribe: <mailto:ecartis@linux-mips.org?subject=subscribe%20linux-mips>
List-unsubscribe: <mailto:ecartis@linux-mips.org?subject=unsubscribe%20linux-mips>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20140605121204.18ee5f2d@gandalf.local.home> <5390A4F0.3000601@gmail.com> <20140605133500.190eb31d@gandalf.local.home> <5390BA9D.3090402@gmail.com> <20140605145339.57c5be79@gandalf.local.home>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7
On 06/05/2014 11:53 AM, Steven Rostedt wrote:
On Thu, 05 Jun 2014 11:44:45 -0700
David Daney <ddaney.cavm@gmail.com> wrote:

But stddev is s64. Ah, but the compare is:

(void)(((typeof((n)) *)0) == ((uint64_t *)0));

so it's complaining about a signed verses unsigned compare, not length.
I think I can ignore this warning then.

The pedant in me thinks that you should fix your code if using do_div()
on a signed object is undefined.  But if you aren't planning on merging
the code, then it probably doesn't matter.

It's undefined on signed 64 numbers?

Evidently it is.

The top of asm-generic/div64.h has:

.
.
.
 * The semantics of do_div() are:
 *
 * uint32_t do_div(uint64_t *n, uint32_t base)
 * {
.
.
.

do_div() really passes the first parameter by reference, and C doesn't have by reference parameters, so the example is not quite right. But it does seem to imply the thing should be an *unsigned* 64-bit wide variable.

It has been like this since the beginning of the git epoch.

Where is that documented.

The code is the documentation.

I don't
see it in the comments, and I don't see anything in the Documentation
directory. It only states that n must be 64bit. It doesn't say unsigned
64 bit.

The handful of call sites I examined, seem to all use u64 or unsigned long long.

I get:

  $ grep -r do_div Documentation | wc
      0       0       0

So it would seem that most of the do_div() documentation actually is the code.

David Daney


<Prev in Thread] Current Thread [Next in Thread>