All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Daney <ddaney.cavm@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ralf Baechle <ralf@linux-mips.org>, linux-mips@linux-mips.org
Subject: Re: gcc warning in my trace_benchmark() code
Date: Thu, 05 Jun 2014 14:56:24 -0700	[thread overview]
Message-ID: <5390E788.2030702@gmail.com> (raw)
In-Reply-To: <20140605145339.57c5be79@gandalf.local.home>

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

  reply	other threads:[~2014-06-05 21:56 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-05 16:12 gcc warning in my trace_benchmark() code Steven Rostedt
2014-06-05 17:12 ` David Daney
2014-06-05 17:35   ` Steven Rostedt
2014-06-05 18:44     ` David Daney
2014-06-05 18:53       ` Steven Rostedt
2014-06-05 21:56         ` David Daney [this message]
2014-06-05 22:17           ` Steven Rostedt
2014-06-06  7:16           ` Geert Uytterhoeven
2014-06-05 21:07   ` Ralf Baechle
2014-06-05 21:38     ` Maciej W. Rozycki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5390E788.2030702@gmail.com \
    --to=ddaney.cavm@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.