qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] or1k: Fix compilation hiccup


From: Markus Armbruster
Subject: Re: [PATCH] or1k: Fix compilation hiccup
Date: Mon, 08 Jun 2020 08:03:20 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Markus Armbruster <armbru@redhat.com> writes:

> Peter Maydell <peter.maydell@linaro.org> writes:
>
>> On Fri, 29 May 2020 at 17:23, Christophe de Dinechin
>> <dinechin@redhat.com> wrote:
>>> On 2020-05-26 at 20:51 CEST, Eric Blake wrote...
>>> > diff --git a/hw/openrisc/openrisc_sim.c b/hw/openrisc/openrisc_sim.c
>>> > index d08ce6181199..95011a8015b4 100644
>>> > --- a/hw/openrisc/openrisc_sim.c
>>> > +++ b/hw/openrisc/openrisc_sim.c
>>> > @@ -129,7 +129,7 @@ static void openrisc_sim_init(MachineState *machine)
>>> >      const char *kernel_filename = machine->kernel_filename;
>>> >      OpenRISCCPU *cpu = NULL;
>>> >      MemoryRegion *ram;
>>> > -    qemu_irq *cpu_irqs[2];
>>> > +    qemu_irq *cpu_irqs[2] = {};
>>>
>>> Why is the value [2] correct here? The loop that initializes loops over
>>> machine->smp.cpus. Is it always less than 2 on this machine?
>>
>> Yes: openrisc_sim_machine_init() sets mc->max_cpus = 2.
>> My suggestion of adding an assert() is essentially telling the
>> compiler that indeed smp_cpus must always be in the range [1,2],
>> which we can tell but it can't.
>
> Do we have a proper patch for this on the list?

Apparently not.

Philippe did try Peter's suggestion, found it works, but then posted it
only to Launchpad.  Philippe, please post to the list, so we can finally
get this fixed.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]