Philippe Mathieu-Daudé <phi...@redhat.com> writes: > On 6/8/20 8:03 AM, Markus Armbruster wrote: >> Markus Armbruster <arm...@redhat.com> writes: >> >>> Peter Maydell <peter.mayd...@linaro.org> writes: >>> >>>> On Fri, 29 May 2020 at 17:23, Christophe de Dinechin >>>> <dinec...@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. > > Sorry since it was Eric finding, I didn't understood I had to post it. > Will do.
You didn't *have* to, but it'll help if you do :)