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.