qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Igor Mammedov <imammedo@redhat.com>,
	QEMU Developers <qemu-devel@nongnu.org>,
	He Chen <he.chen@linux.intel.com>
Subject: Re: [Qemu-devel] [PULL 02/29] numa: Allow setting NUMA distance for different NUMA nodes
Date: Tue, 30 May 2017 13:21:04 -0500	[thread overview]
Message-ID: <075c20c5-3783-ed72-dfe2-52880fec439b@redhat.com> (raw)
In-Reply-To: <20170530181034.GN32274@thinpad.lan.raisama.net>

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

On 05/30/2017 01:10 PM, Eduardo Habkost wrote:
> On Tue, May 30, 2017 at 10:28:21AM -0500, Eric Blake wrote:
>> On 05/30/2017 09:01 AM, Eduardo Habkost wrote:
>>
>>>> The OSX compiler is pickier about format strings than gcc,
>>>> and neither "MAX_NODES" nor "MAX(anything)" are uint16_t type.
>>>
>>> src and dst are both uint16_t, so MAX(src, dst) is also uint16_t,
>>> isn't it?  It looks like MAX_NODES is the problem.
>>
>> No. MAX() invokes arithmetic (both ?: and > operators), and arithmetic
>> involves default promotion (anything shorter than int becomes 'int').
> 
> Oh, I didn't know that.

And the fact that var-arg passing REQUIRES promotion means you CAN'T
tell the difference from a true uint16_t argument and an int argument
which resulted from arithmetic promotion.  Which is why Paolo has argued
that the MacOS compiler warning is bogus because it is overly picky.
But we obviously are in no position to get it changed.

> 
>>
>>> +++ b/numa.c
>>> @@ -232,7 +232,7 @@ static void parse_numa_distance(NumaDistOptions *dist, Error **errp)
>>>      if (src >= MAX_NODES || dst >= MAX_NODES) {
>>>          error_setg(errp,
>>>                     "Invalid node %" PRIu16
>>> -                   ", max possible could be %" PRIu16,
>>> +                   ", max possible could be %d",
>>
>> Don't you want %u to match PRIu16, rather than %d?
> 
> Can't this (using %u with an int argument) make more pedantic
> compilers complain?

Yes, gcc's -Wformat-signedness would (probably) flag it.  But we don't
use that.  At any rate, ALL uint16_t values are formatted identically
for both %u and %d, so as long as we have a formula for keeping picky
compilers silent, I don't care beyond that point.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

  reply	other threads:[~2017-05-30 18:21 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 19:18 [Qemu-devel] [PULL 00/29] x86 and machine queue, 2017-05-11 Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 01/29] i386: rewrite way CPUID index is validated Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 02/29] numa: Allow setting NUMA distance for different NUMA nodes Eduardo Habkost
2017-05-30 10:45   ` Peter Maydell
2017-05-30 14:01     ` Eduardo Habkost
2017-05-30 15:28       ` Eric Blake
2017-05-30 18:10         ` Eduardo Habkost
2017-05-30 18:21           ` Eric Blake [this message]
2017-05-30 17:08       ` Peter Maydell
2017-05-30 17:12         ` Daniel P. Berrange
2017-05-11 19:18 ` [Qemu-devel] [PULL 03/29] numa: equally distribute memory on nodes Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 04/29] tests: acpi: extend cphp and memhp testcase with numa distance check Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 05/29] tests: add CPUs to numa node mapping test Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 06/29] hw/arm/virt: extract mp-affinity calculation in separate function Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 07/29] hw/arm/virt: use machine->possible_cpus for storing possible topology info Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 08/29] hw/arm/virt: explicitly allocate cpu_index for cpus Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 09/29] numa: move source of default CPUs to NUMA node mapping into boards Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 10/29] spapr: add node-id property to sPAPR core Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 11/29] pc: add node-id property to CPU Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 12/29] virt-arm: " Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 13/29] numa: add check that board supports cpu_index to node mapping Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 14/29] numa: mirror cpu to node mapping in MachineState::possible_cpus Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 15/29] numa: do default mapping based on possible_cpus instead of node_cpu bitmaps Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 16/29] pc: get numa node mapping from possible_cpus instead of numa_get_node_for_cpu() Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 17/29] spapr: " Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 18/29] virt-arm: " Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 19/29] QMP: include CpuInstanceProperties into query_cpus output output Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 20/29] tests: numa: add case for QMP command query-cpus Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 21/29] numa: remove no longer need numa_post_machine_init() Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 22/29] machine: call machine init from wrapper Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 23/29] numa: use possible_cpus for not mapped CPUs check Eduardo Habkost
2017-05-17  8:07   ` Markus Armbruster
2017-05-17  9:09     ` Igor Mammedov
2017-05-11 19:18 ` [Qemu-devel] [PULL 24/29] numa: remove node_cpu bitmaps as they are no longer used Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 25/29] numa: add '-numa cpu, ...' option for property based node mapping Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 26/29] tests: check -numa node, cpu=props_list usecase Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 27/29] migration/i386: Remove old non-softfloat 64bit FP support Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 28/29] vmstatification: i386 FPReg Eduardo Habkost
2017-05-11 19:18 ` [Qemu-devel] [PULL 29/29] migration/i386: Remove support for pre-0.12 formats Eduardo Habkost
2017-05-15 13:15 ` [Qemu-devel] [PULL 00/29] x86 and machine queue, 2017-05-11 Stefan Hajnoczi

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=075c20c5-3783-ed72-dfe2-52880fec439b@redhat.com \
    --to=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=he.chen@linux.intel.com \
    --cc=imammedo@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).